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ENHANCED TCAS Il/CDTI TRAFFIC SENSOR 
DIGITAL SIMULATION MODEL 
AND 

PROGRAM DESCRIPTION 
Tsuyoshi Goka 

Analytical Mechanics Associates, Inc. 

Mountain View, California 94043 

SUMMARY 

The objectives of this project were to develop digital 
simulation models of enhanced TCAS Il/CDTI traffic sensors 
based on actual or projected operational and performance 
characteristics. Two enhanced traffic (or threat) alert and 
collision avoidance systems were considered. The main focus 
is a system based on the FAA/Bendix design which dates back 
to the so-called Beacon Collision Avoidance System (BCAS) 
concept. The other system is built by Dalmo Victor Division 
of Textron’s Bell Aerospace Co. based on the FAA/MIT active 
BCAS concept. 

Based on the engineering model, a digital simulation 
program was developed in FORTRAN. The program contains an 
executive with a semi-real time batch processing capability. 

Thus, the simulation program can be interfaced with other 
modules with a minimum requirement. The program is described 
in detail. 

The TCAS systems are not specifically intended for Cockpit 
Display of Traffic Information (CDTI) applications. However, 
these systems are sufficiently general to allow implementation of 
CDTI functions within the real systems 1 constraints. 
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INTRODUCTION 

NASA Langley Research Center is pursuing a research effort con- 
cerning the Cockpit Display of Traffic Information (CDTI) concept. The 
CDTI is a device which presents information to the pilot and crew de- 
picting the status of surrounding traffic including position and velo- 
city states. The general CDTI avionics consists of a "traffic sensor", 
a pilot interface unit, a CDTI signal/data processor, and a display 
unit. 


The pilot interface unit can be a simple on/off switch, a shared 
keyboard, or an elaborate touch sensitive screen. The CDTI signal/data 
processor can be a digital data link between the traffic sensor and 
signal operator or a bona fide computing module performing data edit- 
ing, traffic selection or similar functions. The computational module 
may be imbedded, for example, in a navigation computer. A cathode ray 
tube (CRT) or a flat panel plasma display unit seems to be the most 
suitable display medium. 

Again, this system could be dedicated, shared, or imbedded in with 
other functions. It would most logically be included in an Electronic 
Horizontal Situation Indicator (EHSI) or a Multi-Function Display's (MFD) 
symbology. It is also possible that the CDTI display could be included 
in a general "Air Traffic Control" display unit in a futuristic environ- 
ment if one were to extrapolate the current digital avionics and up-and- 
down link communication technology and the centralized and automated 
ground control philosophy. 

The CDTI functions include both passive (monitoring) and active 
roles. The latter is sometimes referred to as Electronics Flight Rules 
(EFR) as compared to the VFR or IFR control environment. Some of the 
envisioned CDTI functions are listed below: 
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Traffic Monitor Ing Roles : 


General Traffic Monitoring 
Longitudinal Separation of Arrivals 
Independent Parallel Approaches 
Oceanic Route Separation 

Active Control Roles : 

Arrival Merging 

Arrival In-trail Spacing Control 
Enroute Passing and Crossing 
Severe Weather Avoidance 

As can be seen from the above list of functions, the main utility of 
the CDTI is to provide the pilot with a strategic information base which 
allows him to make appropriate decisions. This is counter to other 
avionics which have well defined tactical functions. (For example, the 
MLS (Microwave Landing System) provides deviation signals from reference 
for the pilot to nullify.) This means that the CDTI utility can not be 
measured by quantitative attributes such as accuracy or sampling frequency 
alone. This utility also involves the question of how the pilot uses 
the information base; i.e., the human factors aspect. 

Therefore, various CDTI issues must be resolved via active, pilot- 
in-the-loop simulation studies. This points out the importance of de- 
veloping a realistic simulation facility to reflect a "real" full work- 
load flight environment. This issue is not limited to the "traffic sen- 
sor" modeling, but it includes a host of other simulation elements. 

Because there seems to be no official impetus to develop a CDTI 
traffic sensor per se at this time, an experimental sensor simulation 
model must be developed based on related systems which are currently being 
developed. The FAA developed Traffic Alert and Collision Avoidance System 
(TCAS) comes closest to fulfilling various CDTI research needs. 
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TCAS is strictly an airborne system which provides the aircraft 
separation protection information independent of the ground ATC system. 

The FAA plans call for developing two types of TCAS - TCAS I and TCAS 
II. Within each category, a certain latitude in capability is allowed 
to satisfy a wide spectrum of user requirements. 

The enhanced TCAS II which is capable of obtaining relative bearing 
measurements between the protected (Own) and surrounding aircraft (Target) 
may be able to support CDTI applications. The enhanced TCAS II is capable 
of range and bearing (in addition to the encoded altitude) measurements 
with a medium degree of accuracy to the extent that a more sophisticated 
CDTI type display or horizontal collision avoidance logic may be supported. 
There are two designs in this enhanced TCAS II category. One design, de- 
veloped by MIT/Dalmo Victor (DV TCAS), is based on the so-called active 
Beacon Collision Avoidance System (BCAS) . The other, developed by Bendix 
(BX TCAS), is based on the so-called full BCAS concept. 

In support of the NASA Langley CDTI research effort, a comprehensive 
digital simulation model of the enhanced TCAS II based on the Bendix design 
(BX TCAS) has been developed. The reasons behind this choice are two- 
fold. First, because of its inherent accuracy, other TCAS based traffic 
sensors can be "emulated" by degrading the BX TCAS model performance. 

Second, the versatility of the TCAS processor provides a certain modification 
latitude suitable for CDTI applications. 

This report is a companion to our report entitled "Analysis of Estima- 
tion Algorithms for CDTI and CAS Applications [1]", which studies the sensor 
accuracy analysis with respect to CAS logic and CDTI applications. This 
report is organized as follows. Chapter II provides an engineering descrip- 
tion of the BX TCAS II system. Chapter III provides a detailed description 
of the supporting simulation programs. Chapter IV provides the Input/ 

Output requirements for the BX TCAS module. Chapter V discusses a set of 
simulation validation cases. The validation cases were selected from 
the draft TCAS II Minimum Operating Performance Standards by the 
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RTCA SC-147 [2], Chapter V provides the conclusions. Appendix A lists 
all the major commons used In the simulation program. Appendix B dis- 
cusses the major functional departure for the Dalmo Victor TCAS II (DV 
TCAS) design. It also includes a set of program modifications in order 
to incorporate system peculiarities. 
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II 


ENHANCED TCAS II DESCRIPTION 
Background 

TCAS provides information for safe aircraft separation independent of 
the ground ATC sensors. Except for TCAS I (which operates on a passive 
listening mode in principle), TCAS contains an (active) transmitter as well 
as an ICAO approved Model S transponder. Target relative positional measure- 
ments are acquired by means of radio frequency (RF) transactions of 1030 MHz 
interrogation transmission and 1090 MHz reply reception. (Note that the RF 
formats are compatible with the current ATC surveillance system requirements.) 

Four major submodules — surveillance, state estimation, collision 
avoidance logic, and pilot warning and display — further process the RF 
transactions to satisfy the aircraft separation requirements. Figure 1 depicts 

JL 

the functional break-down of these four submodules . Each of these submodules 
will be discussed in subsequent sections. 

A relative bearing measurement capability is not a requirement for minimum 
TCAS II; the bearing capability constitutes the "enhancement". Enhanced TCAS II 
is capable of range and bearing (in addition to the encoded altitude) measure- 
ments with a medium degree of accuracy to the extent that a more sophisticated 
CDTI type display or horizontal collision avoidance logic may be supported. 

Two systems in this category are at various stages of development or 
testing. 'Flight evaluation of the DV TCAS will begin shortly in scheduled 
operational environment [3]. The TCAS generated advisories will be displayed 
to the flight crew. The BX TCAS engineering unit is currently undergoing an 


* It is noted that the time sequence of events over one TCAS cycle is 
closely correlated with the top to bottom items, i.e., the collision 
avoidance logic requires the latest available state estimates which, 
in turn, depend on the latest available surveillance data. 
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Figure 1. TCAS II Functional Elements. 



















extensive flight test evaluation [A]. Table 1 shows the over-all performance 
and operational characteristics of these two systems. Table 2 shows the 
consensus of engineering opinion indicating the TCAS functional breakdown 
and bearing accuracy. 

In subsequent sections, functional descriptions of the four submodules 
are given based on the BX TCAS design. It seems to be more suitable than 
the DV TCAS for the CDTI applications in terms of coverage volume, accuracy, 
and versatility. The material presented here is condensed, mainly from 
the draft TCAS II MOPS and Bendix reports [1,5, 6, 7, 8]. 


Table 1. Operational Characteristics of Candidate TCAS CDTI Sensors 


1 — r 

DV TCAS II 

BX TCAS II 

Mode Base 

• Aircraft based 

• Independent of ground 

• Aircraft based 

• Independent of ground 

Coordinate 

System 

• Aircraft • fixed 

• Aircraft Body Axes 

• Aircraft fixed 

• NED Local Level 

Coverage 

• Within 10 nmi (max) of 
Own 

• Within 25 nmi (max) of 
Own 

Accuracy 

• range = 100 ft rms 

• bearing = 6-8 deg rms 

• altitude ■ 100 ft reso- 
lution 

• range = 100 ft rms 

• bearing = 2 deg rms 

• altitude * 100 ft reso- 
lution 

Sampling 

Rate 

• 1 sec 

• reliability ■ f (range) 

• 1-8 sec (variable) 

• reliability high 

Comments 

• aB tracker in r-B axes 

• LO tracker (altitude) 

• Estimate not stabilized 
with respect to Own 
attitude 

• Global protection 

. Medium traffic density 

. aB tracker in x-y axis 
. LO tracker (altitude) 

. Estimate stabilized with 
respect to Own attitude t 
i.e., <(>, 0, ^ are avail- 
able within the TCAS 
processor 

. Global protection 
. High traffic density 













Table 2. Functional Breakdown of TCAS II 
with Respect to Bearing Accuracy 



Bearing Accuracy 
(deg) 

Function 

Enhanced 
TCAS II 

4-8 

o Vertical Resolution 
(bearing modified) 

o PWI or CDTI 

0.6 - 2 

o Horizontal and 
Vertical Resolution 

o CDTI 


Surveillance 

The surveillance process begins by the TCAS transmitting 1030 MHz 
interrogation signals and by receiving 1090 MHz replies from nearby 
transponders (Mode A, ATCRBS or Mode S) or by listening for Mode S squitter 
or air-to-ground transmission signals at 1090 MHz. The position measure- 
ments are then computed by the internal signal processor as follows: 

(a) range - by the time duration between the interrogation and 
the corresponding reply reception, accounting for the trans- 
ponder delay; 

(b) bearing - by computing the angle-of-arrival from the phase 
distribution among several antennas; and, 

(c) altitude - by decoding the Mode C altitude code contained in 
the reply. (For a Mode A only target, this will be non- 
existent. ) 

The surveillance characteristics of the BX TCAS are somewhat similar 
to that of the ground based Mode S beacon sensor. Because a large number 
of transmitters in a small local will cause interference resulting in 
synchronous garble, fruit or false squitter detection, there are three 
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techniques (in addition to the mono-pulse technique) to overcome the high 
density problem. One is the interrogation antenna directivity; the second 
is the so-called "whisper /shout" signal power level sequencing; and the 
third is the Interrogation rescheduling if a reply is missed or garbled. 

The antenna beam width is 22 1/2 deg; however, by* repeating the trans- 
mission four times and each time sliding the beam center by 5.625 deg, the 
effective beam width becomes 5.625 deg. The beam pointing and rescheduling 
as well as several levels of whisper/ shout power sequencing are controlled 
by internal digital processors based on the internal track file. Own 
aircraft’s orientation, and the ATCRBS/Mode S transponder mix. The task 
is facilitated by the fact that the beam is "stabilized" with respect to 
roll, pitch and yaw attitude angles. 

Target Track Establishment The function of establishing the target 
track consists of two subfunctions: relative position measurement and the 

associated target correlation. The position measurement refers to the 
actual RF activities between Own f s transmitter /receiver and Target’s trans- 
ponders and the subsequent signal processing to extract the position measure- 
ment. The correlation process (also referred to as the track acquisition or 
establishment) establishes the correspondence between a set of measurements 
and a particular tracked aircraft. 

It is simple to track Mode S equipped aircraft because of the uniquely 
assigned discrete address in the reply format (which is also stored in the 
TCAS unit). The task of correlating between the measurements and the tracked 
aircraft is not as simple if the target is Mode C or Mode A equipped. Also, 
for the narrow beam system (BX TCAS) , the correlation process is simpler 
than for the omni-directional or wide angle system, because the number of 
replies corresponding to an interrogation is generally much smaller. However, 
even the narrow beam width and the rescheduling capability present problems 
if two or more aircraft are clustered in close proximity. 

A "gating" technique is used for the purpose of separating targets. If 
the current measurement falls within certain threshold values (which define 
the gate) of the predicted value of an aircraft in the track file, then the 
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measurement is assigned to that aircraft, and the corresponding track file 
is updated. If the measurement does not correspond consistently (5-10 sec) 
within a gate to any existing aircraft in the track file, then a new track 
file is started for that set of measurements. Conversely, if none of the 
measurements consistently correspond to an aircraft in the file, then that 
aircraft is judged outside the beam reach, and hence, it is deleted from 
the track file. 

The state estimates play an important role in computing the prediction 
since the last valid measurement time. The estimation algorithms used for 
this purpose are classical simple alpha-beta trackers. Accuracy is not too 
critical because the threshold values are sufficiently large to account for 
estimation errors. 

There are still problems with the TCAS system proto-type which is 
currently being flight tested. Track establishment of an ’'image target” 
due to multi-path of the real target is one of the remaining major problems. 

Coverage Volume The Own protected airspace provided by the system is 
physically limited because of transmitter power output and/or receiver 
reception sensitivity limitations. Also, the beam pattern due to the antenna 
configuration comes into play, especially for the vertical coverage. The 
maximum beam reach is estimated to be 35 nmi; this is at the highest sen- 
sitivity level. Within this distance, the 1030 MHz transmission signals 
can be distinguished from the ambient RP noise with a certain reliability. 

The vertical limitation is due to the elevation beam shape. The top 
mounted antenna assembly is designed to provide coverage of approximately 
five (5) deg below and 23 deg above the antenna plane. The system may or 
may not include a similar antenna assembly located at the bottom of the 
fuselage. 

To limit unnecessary KF activity, especially in a high traffic density 
area, the BX TCAS relies on an ”artif icial" boundary generated by the beam 
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control microprocessor. The volume is dynamically computed and is defined 
by the relative range and relative altitude. In case of a Mode A transponder, 
the range defines the volume. Furthermore, the volume is subdivided into 
two regions - "acquisition" and "track". 

The acquisition region is provided mathematically by 

Ar £ Ar acq , and [ Ah| £ Ah acq . (!) 

Here Ar is the (acquisition) range threshold (nominally 17 nmi for Mode A 
acq 

and Mode C transponders and 25 nmi for Mode S transponders) , and Ah acq is 
the altitude threshold (nominally 6,000 ft but ignored for Mode A transponder) 

The track region is provided mathematically by 

Ar £ Ar trk , and | Ah| £ Ah trk . C 2 > 

Here Ar , is the (track) range threshold which is computed dynamically, 
trie 

and Ah trk is the altitude threshold given by 

Ah trk = 3750 + | z | • 45 (ft) . (3) 

The quantity Ar , is determined based on the relative bearing as well as 
cr n 

Own ground speed and altitude* The equation defining for this term is 
given by 

Ar t rk = MaxUr llm> (V Q cosAb + V^) T + Ar g ) C 4) 

Here, 

A 

Vq = Own ground speed, in kt, 

T = "closure" time constant = 1/80 hr = 45 sec, and 

Ab = relative bearing with respect to Own's body axes 

= tan" 1 (Ay B /Ax B ) 

Ar = 1.65 nmi. 

s 

Ar and V w are computed based on Own altitude z (ft) , according to 
lim Max r ° 


11 




( 5 ) 


( 6 ) 


Figure 2 shows the track regions corresponding to three Own ground speeds 
at three Own altitude levels. It is noted that the Own forward direction 
is given a heavier protection weight. 


Interrogation Schedule Logic The antenna pointing controller module 
schedules the interrogation and reception timing (i.e. , surveillance 
scheduling). The surveillance operation depends on two factors. One is 
the transponder type - Mode C or Mode S. The other is the operational 
mode - sear ch/acquisit ion or track. The antenna dwell at a given azimuth 
angle is divided into one passive and three active processes. The active 
ones include: (a) ATCRBS transmissions to search for new targets (targets 
which are not in the internal track file); (b) ATCRBS transmissions for 
tracking existing targets (in the internal track file); and (c) Mode S 
transmissions for tracking Mode S equipped targets. The passive process 
consists of possibly listening for Mode S squitters or Mode S replies to 
ground interrogations. 


The time interval between ATCRBS search interrogations. At , is 

s 

computed according to the formula: 

3600 Ar 
s 

V. + V_cosAb 
Max 0 

where the variables have been previously defined. 




The ATCRBS track interrogations are made for those targets lying 
inside the track volume satisfying Eq. (2). The ATCRBS track interrogation 
time interval, At T , is computed based on the predicted relative motion of 
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nmi 



Figure 2. Range Track Regions 

at Various Own Altitudes. 
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the target. It is given by the formula 

At^ = Max {1 sec, min {t^, t 2 » t^, 8 sec} }. (8) 

Here, 

t^ = the number of seconds it will take the target 
to move 3 deg in bearing, 

t 2 = the number of seconds it will take the target 
to move 1000 ft in range, and 

t^ = the number of seconds it will take the target 
to move 250 ft in altitude. 

Interrogation scheduling logic for targets with Mode A transponders 
is presumed to be similar to the ATCRBS interrogations. However, the 
target altitude logic would be ignored. Furthermore, if Own altitude is 
too high compared to the FAA’s altitude encoding transponder requirements, 
then the Mode A targets can safely be ignored. 

The interrogation scheduling logic for targets with Mode S transponders 
are similar to the ATCRBS transponder case. When a new Mode S target is 
detected by squitter listening, it is interrogated. If it is within the 
acquisition range, Ar , a track is initiated. Mode S equipped targets 

3C(J 

inside the track volume are interrogated at the same rates as if they were 
ATCRBS targets. Those targets which are outside of the volume but within 
^ r aC q are trac ^ ec ^ at a regular interval of eight (8) sec. 

If a target (either ATCRBS or Mode S equipeed) is closer than 6000 ft 
or if it has been declared a preliminary threat by the threat direction logic, 
the target track update rate is one (1) sec. 

If replies are missing under repeated interrogation of a tracked target, 

the track is dropped. In addition, ATCRBS tracks will be dropped when their 

coasted position (position extrapolated by dead reckoning) lies outside of 

the track volume. A Mode S track will be dropped when the expected range 

is greater than Ar . Table 3 summarized the surveillance function, 
acq 


16 


, ATCRBS (Mode A or C) 

Mode S Transponder Transponder 


Table 3. Summary of BX TCAS Surveillance Function 


Target Search or 
Acquisition 


IF (Ar < Ar .AND. 

— acq 

|Ah| < Ah ) THEN 
i i — acq 

At = min{At, 16 sec} 
s 


3600 • Ar 
s 

V M + V.cosA 
Max 0 b 


Target Track 


(i) IF (threat .OR. Ar £ lnmi) , 
THEN At x - 1 sec, or 

(ii) IF (Ar £ Ar fcrk .AND. 

| Ah | £ Ah. ) , THEN 


At T = Max{l sec, min 

Ctj^t^t^ 8 sec}} 


Passive listening for 
Mode S squitters or 
replies to the ground 
Mode S interrogations. 


(i) IF (threat .OR. Ar £ lnmi) , 
THEN At T = 1 sec, or 


(ii) IF (Ar < Ar .AND. 
' — acq 

|Ah| < Ah ), THEN 
1 1 — acq 

At = 8 sec 
s 


(ii)IF (Ar £ Ar trk .AND. 

| Ah | £ Ah trk ), THEN 

At T = Maxtl sec, min 

(t 1 ,t 2 ,t 3 , 8 sec}} 


17 nmi (Mode A and C) ; Ah = 6000 ft ( Mode c ^ s) 

25 nmi (Mode S) acq 

ax j Ar s + (V 0 cos Ab + V^) T, Ar llm jj 4^-3750 + ^ 

5 nmi , < 10,000 ft 

10 nmi , otherwise 


./20 + 100 ; with 250 £ V £ 600 


1.65 nmi 

= Own ground speed, altitude and altitude rate est im ates 
number of seconds for 3 deg bearing change 
number of seconds for 1000 ft range change 
number of seconds for 250 ft altitude change 







Surveillance Reliability Surveillance reliability is defined as the 
probability of obtaining a correlated set of measurements for an aircraft 
within the track file. The exact numbers are not known. The probabilities 
of 0.99 for Mode S, 0.95 for Mode C, and 0.9 for Mode A transponders seem 
to represent state-of-the-art. 


Estimation 

The estimation submodule generates estimates of suitable state variables 
for the surveillance and CAS submodules based on the relative range and 
bearing measurements, target altitude report, and Own altitude input. In 
actual implementation, parts of the estimation function may be distributed 
in other submodules depending on their needs. For example, a simple low 
gain alpha-beta tracker may be used in conjunction with the Mode C altitudes 
reports within the surveillance module. The tracker outputs are used for 
track establishment and correlation purposes via the previously mentioned 
altitude gating technique. 

On the other hand, the collision avoidance logic requires more accurate 
estimates. Thus, it contains a separate, more complex non-linear vertical 
tracker algorithm as an integral part. One question is: Why is the nonlinear 

tracker not used for the surveillance applications as well? One reason 
is that the computational time requirements are high. At any one time, the 
number of threats within the CAS traffic file is limited to 5 or 6, whereas 
the number of tracks (that may include multi-path images) within the 
surveillance track file could be ten times as large. With the more time 
consuming algorithm, all the entries in the traffic file may not be completed 
within the time allocation of a fraction of one second. 

Because the CAS application needs are more acute compared to the 
surveillance needs in terms of estimation accuracy, the subsequent discussion 
will emphasize the CAS aspects. (CDTI accuracy requirements are thought to 
be similar.) 
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The BX TCAS design relies on north referenced local level x and y 
components* as the basis for the horizontal position and velocity estimates. 
This is accomplished by utilizing Own roll, pitch and yaw angles. This 
approach is discussed in the following sections. 

Measurement Accuracy The error characteristics for the BX TCAS in 
an operational environment are virtually unknown. The following character- 
istics represent a consensus of the immediate engineering community and are 
also inferred from a limited number of flight tests. A proto-type model has 
been in flight tests since January 1984. 

Because the interrogation/reply process of this unit is similar to 
the Mode S ground sensor, it is reasonable to assume that the range error 
could be as accurate as + 50 ft (+1 cj). A standard deviation of + 75 ft (+lc0 
is assumed for the simulation. 

The bearing error depends on the sharpness of the directional beam 
and the internal clocking device. It also depends on the reflection 
(multi-path) characteristics from various points on the target and the 
Own aircraft fuselage. The consensus value for this error is between 
+0.6 and +2 deg (+lcr). A standard deviation of +1.0 deg (+lcr) is assumed. 

See Table 2. 

The 100 ft quantization due to the encoding process dominates the 
altitude error. Twenty— five (25) foot seems to be a reasonable standard 
deviation number for the high frequency error; however, low frequency 
drift, bias or scale factor errors could be substantially larger with up 
to a +4 % scale factor error not being uncommon. 

Coordinate Systems Two coordinate systems are important in BX TCAS 
sensor geometry. One is a north referenced local level coordinate system 
attached to the fuselage at the antenna. The other is the orthogonal 

* The draft TCAS II MOPS recommends that orthogonal linear 

dimensions be used rather than range and bearing dimensions, 

even though 0 and ^ are not available. 
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coordinate system attached to the antenna plane, i.e., the aircraft body 
reference system. Figure 3 depicts the transformation geometry. 

The relative bearing is measured with respect to the latter reference 
(the relative range is coordinate free); whereas the relative position 
(say, north-east-down) is measured in the local level system. 

Using the conventional definition of Euler body angles <{>, 0 and rp, 
the transformation (Tg^) from the local— level to Own body axes is given by 


c0cij> 

C0s^ 

-S0 

- c4>si^> + s4>s0sij/ 

C$c^/ + S<J>S0S^ 

S$C0 

SIpSlp + C$S0C1|> 

-s<J)C^ + c<{>s0s\J; 

C(f>C0 


Using this transformation, a relative north-east-down position vector 
to a target aircraft transforms to one in the body axis as 


(9) 


T 1 

J 


Ax 

a *b 

= T 

BL 

Ay 

- A \ 


Az 



_ «, 


( 10 ) 


The relative bearing and elevation angles to the target are given by 
Ab » tan 1 (Ay^/Ax^) , 

_1 (ID 

Ae = tan (Az fi /Ar) 


20 



♦z 

DOWN 


Figure 3. TCAS Geometry 
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Inverse Transformation One requirement is to transform the TCAS 
measurements to north referenced x and y components. These measurements 
include the relative range and bearing (Ar and Ab) , the target and Own 

A A 

estimated altitudes (z T and z^) and the measured Own attitude angles 
(<J>» 9 and \p). It is a reverse problem of finding Ab given x, y and z. 


The following equation is obtained by using Eq (10): 


Ax 


rN 

Ay 

= T 

LB 

a ?b 

Az 


_ Az b_ 

. _ 



( 12 ) 


Here ’ T lb is 



be written as 


the 

The 


body-to-local-level direction cosine matrix given by 
body referenced position vector (AXg, Ay g and Az 0 ) can 


_Ax b' 


cos(Ae) cos(Ab) - 

a *b 

= Ar 

cos(Ae) sin(Ab) 

Az b 


sin(Ae) 


(13) 


where Ae is the unknown elevation angle. 

Substituting Eq (13) into Eq (12) and writing out the third row 
equation, it follows that 


~ cos (Ae) + ^ sin(Ae) , ( 14 ) 



A 1 = TlbCS, 1 ) cos(Ab) + T lb ( 3,2) sin(Ab), ( 15 ) 

A 2 = T LB^ 3,3 ^ » 


and T LB (l,j) is the ji c ^ element of the matrix of Eq (9). 
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Now define 



A 




i4 + 4 ]1/2 * 

fe w 1 • 

A 1 |a| 1 , and 



( 16 ) 


Then, sin(Ae) and cos(Ae) are given by 
sin(Ae) - CA£ - (1-C 2 ) 1/2 A£ , 
cos(Ae) = CA£ + (1-C 2 ) 1/2 A£ . 


(17) 


The body referenced positions (Ax^, Ay^ and Az^) can be computed by 
using Eq (13). From these the north referenced relative positions, 
(Ax and Ay) can be directly computed by using Eq (12) . 


In the BX TCAS, the roll and pitch stabilized bearing angle, B, is 
computed from the predicted Ax and Ay by 

B = tan - ^ (Ay/Ax) - if . (18) 


It is used for the beam pointing mechanization for the next interroga- 
tion period. 

When Own and 9 are zero, it can be shown that 

Ax = Ar cos(iIi + Ab) , 

(19) 

Ay = Ar sin(if< + Ab) 

In general, when <j> and 9 are non-zero, the above relationships do 
not hold. However, they may be used as an approximation if and 0 are 
small. 
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Horizontal x-y Tracker Algorithm The horizontal position and velocity 
estimates are obtained by using standard fixed gains in a two-state filter 
called an alpha-beta tracker. The north referenced position computed in 
the last section provides the input to the algorithm. 

Equations for the standard a3 tracker algorithm are given below for 
the x axis. Equations for the y-axis are entirely analogous. 


Prediction: 

o 

* + 

II 

A 

Ax t , 
old 

$ 

+ I-ix oia 

Innovation: 

Ax 

i m 

Ax 

new 

- ix + 

Position Update: 

Ax = 

new 

Ax + + 

a • Ax 

Velocity Update: 

c* 

Ax = 

new 

t 

Ax n , 
old 

+ Ce/T) • Ax 


where T is the time elapsed since the last valid measurements. The 
a and 3 filter gains are optimized with respect to the measurement noise 
and target maneuver levels as well as the sampling period, T. The 
optimal values are listed in Table 4. 

Table 4. BX TCAS Horizontal Tracker a and 3 Gain Values 


r " - , 

T 

sec 

1 

2 

3 

4 

5 

6 

7 

8 

a 

0.25 

0.37 

0.465 

0.53 

0.58 

0.62 

0.645 

0.665 

3 

.066 

.175 

.3 

.431 

.565 

.685 

.886 

.91 

J 


The first two consecutive valid measurements can be used to initialize 
the estimates. This is effective when the sampling period is long. If 
the noise levels are too high, more measurements can be used to initialize 
by using a least squares fit. 
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When the measurement is invalid, the predicted value, given by Eq (20. a), 
is used as the measurement, i.e., the position estimate is coasted until 
the next valid measurement. 

Own Altitude Tracker Algorithm The CAS logic requires both Target 
and Own altitude and altitude rate estimates to assess the vertical threat 
situation. The Target altitude is provided by the Mode C (or Mode S) 
reply with the standard 100 ft quantization. Two methods are available 
for Own altitude estimation. One is to use the Own Mode C signal with 
the 100 ft quantization. The other is to use pressure altitude at a 
finer quantization. Referring to Fig. 4, the finer quantization signal, 
for example, can be obtained by tapping the transducer output channel 
just prior to the Mode C encoder. The finer quantization signal is more 
suitable for estimation purposes. In this case a simple alpha beta tracker 
is used. The algorithm is given by Eq (2) (substitute z^ for x^) . The 
recommended a and 3 gains are 0.5 and 0.15. If only the 100 ft quantized 
altitude is available for Own, then a nonlinear tracker algorithm (dis- 
cussed in the next section) needs to be used. 

Target Altitude Tracker Algorithm A simple low gain alpha beta 
tracker algorithm given by Eq (20) is used within the surveillance 
module. The recommended gains are 0.28 and 0.06 for a and 6, respec- 
tively. These values are presumably tuned at the nominal TCAS surveillance 
cycle period of one (1) sec. 


r "*0 


Static 

Pressure 

-H 

Transducer 

b-H 

Mode C 

Quantizer 

Source 



1 1 





1 

1 





TCAS 

Quantizer 


Pilot Display 


Transponder 

Altitude Data 


TCAS Altitude 
Data 


Figure 4. Schematic Diagram of Altitude Measurement Process. 
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A more complex nonlinear tracker is used by the CAS logic to track 
Mode C altitude reports. The algorithm is based on the so-called Level 
Occupancy Time (LOT) tracker designed for active BCAS application [9,10]. 

The basic idea of the LOT tracker is to estimate the altitude rate 
indirectly by estimating the time duration (called the level occupancy 
time) in a particular quantization level. If the altitude rate is con- 
stant, then so is the time duration. The estimate of level occupancy 
time, T, is given by 

T - T + k (T - T), 0 < k < 1, (21) 

meas 


where 


T 

meas 


t . 

jump 


t 


last jump. 


( 22 ) 


Then, the altitude rate estimate is given by 
z = 100/T . 


(23) 


Some of the ramifications of the LOT tracker algorithm are: 

(1) it requires at least two level changes to obtain 
rate information; and 

(2) it requires at least three level changes to ascertain 
a change in rate (acceleration). 


Therefore, for example, in the case of level-to-climb flight, it must 
wait approximately 3*(100/z) sec before a reliable rate estimate is 
obtained. The above time duration is approximately 36 sec for a 
500 ft/rain vertical rate. The time delay of 36 sec is very significant 
when 30-45 sec is the CAS time constant. 


The altitude sampling period is assumed to be one (1) sec. It is 
not known what the effect of the variable sampling period employed in 
the BX TCAS would be on the tracker performance. 
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Collision Avoidance Logic 


Two types of CAS logic, vertical or horizontal, are planned for 
enhanced TCAS implementation. The vertical logic monitors the relative 
range and altitude states and performs the separation in altitude via 
altitude rate command, if necessary. The horizontal logic monitors the 
horizontal x and y and altitude states and performs the separation either 
horizontally or vertically. The added dimension presents two advantages: 

(a) more accurate situation assessment leading to a less frequent false 
alarm rate; and (b) a longer time period before the actual escape maneuver 
must take place. However, it requires use of a more accurate bearing 
sensor resulting in a higher system cost. 

The vertical CAS logic has matured to the point that a version implemented 
in the DV TCAS is being flight tested in regular commercial airliner opera- 
tion. The horizontal CAS logic is under development. A vertical only BX TCAS 
may soon be in a controlled flight test stage. For this reason, only the 
vertical logic is discussed here. 

Referring to Fig. 1, the CAS logic consists of three major components - 
threat detection, threat resolution and maneuver coordination logic. The 
threat detection logic identifies the threat status of surrounding traffic. 
Furthermore, if a threat is dangerous, then the resolution logic determines a 
proper (vertical) escape maneuver. These are the basic ingredients. The man- 
euver coordination logic which is influenced by the implementation aspects 
consists of multi-threat logic and coordination logic with other TCAS systems. 

The multi-threat logic is needed to resolve the maneuver commands caused 
by more than one threat. This consideration affects the command generation. 

The coordination logic consists of two functions. One is to notify 
TCAS I equipped aircraft what Own intends to do and to communicate appropriate 
data. (Currently TCAS I is envisioned to be a totally passive system or a 
Mode S transponder with a pilot display/ interface device.) The other function 
is to coordinate, resolve and communicate between Own and other TCAS II 
equipped aircraft. This is necessary to prevent both TCAS systems from 
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generating maneuver commands independently which would aggreviate the 
threat situation further. Briefly, this is accomplished by one TCAS 
locking out the other. 


Detection Logic 

Threat status is classified into three threat levels called Advisories. 
These are Proximity, Traffic or Resolution Advisories. In the following 
sections, each classification logic as well as the maneuver command genera- 
tion are discussed. 

TCAS Sensitivity Level Selection The TCAS operating envelope is 
indexed by a parameter called the Sensitivity Level which ranges from 1 through 
7. Level 1 is a standby condition in which TCAS does not interrogate and 
therefore does not perform any surveillance or resolution. This level is 
used only when TCAS has no collision avoidance responsibilities. In 
sensitivity level 2, TCAS continues surveillance, but is inhibited from 
declaring threats (and thus from issuing a resolution advisory) . TCAS may 
generate traffic advisories in sensitivity level 2. Sensitivity levels 
3 and 7 are reserved for future usage. Levels 4, 5 and 6 define a progres- 
sively "larger 11 protection volume. 

The sensitivity level depends on three factors: 

(a) pilot manual selection; 

(b) uplink from the Mode S ground sensors; and 

(c) radio and/or baro altitude. 

The selection logic is as follows: 

(1) Select the lowest level among the uplinked values, if any; 

(2) Otherwise, select according to the altitude schedule - Table 5; 

(3) Finally, use the pilot selected value, if it is lower. 
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Table 5. Sensitivity Selection Altitude Schedule 


Sensitivity 

Level 

Condition 

2 

Radio altitude less than 500 ft j 

4 

Radio altitude between 500 and 2500 ft 

5 

Baro altitude less than 10,000 ft 

6 

Baro altitude greater than 10,000 ft 


Proximity Advisory Detection Logic An intruder reporting Mode C 
altitude qualifies for a proximity advisory if range and altitude are 
small. These thresholds are 2 miles and 1200 feet, respectively. An 
intruder not reporting altitude, (i.e. , Mode A only transponder) quali- 
fies for a proximity advisory if its range is small and if Own is in the 
airspace in which altitude reporting is not required. This threshold 
is 15,500 ft. 

Traffic Advisory Detection Logic The logic consists of two tests — 
range and altitude . These must be satisfied simultaneously in 
order to be declared a Traffic Advisory (TA) threat. 

TA Range Test: Three cases are examined - range magnitude, range 

convergence, and range divergence cases. Table 6 lists the logic. 

Table 6. TA Range Test 



Conditions for Passing 

Magnitude 

Ar < 9. 

- 4r TA 

Convergence 

(Ar < Ar ) 

— mux 

- (Ar - ir TA )/f' i«„ 4 , 

i' - mln(i, - Ar mln ) 

Divergence 

Ar ♦ Ar < 0 RTA .AND. Ar < Ar TA 

1 
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The parameter, Ar^ n (nominally + lOf ps) , represents the extent to which 
the range rate can be estimated accurately. Other parameters 0^.^, Ar TA , 0 RT 
and are mostly logic thresholds and depend on the TCAS sensitivity 

level. Specific values are given in Table 7. 

TA Altitude Test: If the intruder is not capable of altitude 

reporting, then the test is passed automatically if Own aircraft is in 
the airspace in which altitude reporting is required. This threshold is 
again 15,500 ft or below. 


For altitude reporting intruders, the test is slightly more involved. 
It is convenient to define the following relative altitude variables: 


A A 



Ah = | Az 


Az 

Ah 



sign (Az)Az 


(24) 


The altitude test consists of two subtests - magnitude and convergence 
tests. Table 7 lists these tests. 


The parameter, Ah ^ (nominally - 1 f ps) , represents the minimin 
convergence threshold. ^Ah^ magnitude threshold, nominally 1200 ft. 

The parameter 0^^ * s t * ie altitude closure time (tau) threshold, and its 
value depends on the sensitivity level. See Table 8. 

It is noted that the threshold values corresponding to levels 3 and 7 
do not have any significance at the current time. It is also noted that the 
main purpose of PA and TA is to help the pilot visually acquire the intruder. 

Table 7. TA Altitude Test 



Conditions for Passing 

Mode A Only 

z < 15,500 ft 

o — 

Magnitude 

4h * «... 

- lh TA 

Convergence 

Ah < Ah min .AND. - Ah/Ah < 0^ 
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Table 8. TA Threshold Values 


Parameter 

Unit 

Sensitivity Level 





2 

3 

4 

5 

6 

“ r 

Ar TA 

nmi 

.10 

.13 

.20 

.40 

1.20 

1.60 

0 HTA 

nmi^/s 

.00160 

.002 

.00278 

.00278 

.00278 

.004 

~T I 

4r TA 

nmi 

.25 

.35 

.50 

.75 

1.50 

2.00 

9 rta 

s 

20 

30 

35 

40 

45 

48 

0 HTA 

s 

20 

30 

35 

40 

45 

00 


Resolution Advisory Detection Logic This logic determines which 
intruders are predicted to be sufficiently close in range and altitude to 
require a resolution advisory. Similar to the Traffic Advisory logic 
both range and altitude are tested based on the estimated relative kinematic 
variables - Ar, Ar, Az and Az (see Eq. (24) for definitions). If either 
test is not satisfied, an RA is not generated against the intruder. If 
both tests are satisfied, then the reliability of estimates are tested. 

This logic is necessary because, for example, the intruder altitude estimate 
contains a long dynamic delay. 


Once an intruder is declared a RA threat, it remains in this status 
until either range or altitude test fails. It is also forced to remain 
a threat for at least five seconds to avoid overly brief displays of 
advisories. 

No RA is issued for intruders not reporting altitude. In the interest 
of keeping the simulation program relatively simple, it is assumed that 
the simulated threat encounters are limited to single intruder cases. 

Actual TCAS logic contains a multi-threat encounter test by examining the 
internal threat intruder file. 
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Several of the thresholds used in the logic vary with the sensitivity 
level index. Higher sensitivity levels imply higher altitude flight (in 
non-terminal areas); this implies larger altimetry errors and sparser traffic. 
The detection thresholds are therefore made larger to help overcome the 
altimetry errors and to minimize the number of unwanted alerts in the 
sparser traffic environment. Lower sensitivity levels, on the other hand, 
imply lower altitude flight (in the vicinity of a terminal), which implies 
smaller altimetry errors and denser traffic. The detection thresholds 
are therefore made smaller in order to reduce unwanted alerts. 


Range Test: The range test is divided into two cases - range convergence 

(negative range rate) and range divergence (positive range rate) . 

Figure 5 depicts the criteria in the range - range rate plane. Each of 
these cases are discussed in more detail in the following paragraphs. 


In the case of a converging intruder, the criterion is simply that the 

j 

range closure time (called tau) to the Closest Point of Approach (CPA) be 
small. The standard tau, x^, is computed as range divided by range rate. 

A modified tau, x^ , is computed in the same way except that the mini mu ni 
range guard, Ar^ is subtracted from the range. In equation form 

t = Ar/Ar , 

(25) 

T r = (Ar " Ar RA )/A ’ r * 

Mainly, x^ is used for the converging intruder. The rationale is that when 
the range rate is large, then x^ and x' are similar in magnitude; but when 
range and range rate are both small, then x f may be large whereas x£ is 
small. The range test is given by 


x 

r 


- RRA 


(26) 


The parameters, Ar^ and 0^^, are dependent on the sensitivity level index. 


For the non-converging case, the test is similar to the corresponding 
TA range test, i.e.. 


Ar 


< Ar A 
— RA 


.AND. Ar * Ar 


< 0 
- HRA 


( 27 ) 


The RA range tests are summarized in Table 9. 
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Ar 



Figure 5. Region Defining RA Range Test 


Table 9. RA Range Test 



Conditions for Passing 

Convergent 

(aV ± A 'W 

- (Ar - Ar RA )/Ar - 6 m > 

* r * • , 

Ar = miniAr, - Ar^^l 

Divergent 

Ar > Ar . 

mm 

A A • 

Ar < Ar .AND. Ar • Ar< 


i 
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Altitude Test: The RA altitude test is more complex compared to the 
Traffic Advisory test. The shaded region of the (Az, Az) plane in Fig. 6 
represents geometries that pass the altitude test. Linear lines are 
related to vertical closure times and the horizontal lines (Az = + © z ) 
represent minimum vertical separation. There are two cases to consider. 

The altitude tests depend on the vertical miss-distance, Az + , at the CPA 
(minimum range). It is given by Table 10. 

The following tests constitute the RA altitude logic. 

ti) When the current vertical separation is small, then the vertical 
miss-distance, Az + , is tested. Thus, the criteria is given by 

|Az| < 0 z .AND. |Az + | < 0 z , (28) 

where the threshold parameter © z depends on Own altitude. 


Table 10. Vertical Miss-Distance Computation 


Vertical ?liss-Distance 

Condition 

Comment 

Az 

Ar > 0 

Range diverging 

Az+ 

Az* = Az* 

Range Converging 

0 

■f 4* 

Az^ • Az^ < 0 

min(Az*, Az* + 100} 

Az* > 0 

Max{Az*, Az* + 100} 

Az* < 0 


r • 

x. = minl-Ar/Ar', x } 

1 vc 

x = min{-(Ar - 6r)/Ar", x }, Ar' = min{Ar, -Ar . } 

^ vc mm 

Az? = Az + x n Az ; Az = z - z T , Az = z - z T 

-L O I O I 

+ « 

Az^ = Az + x^Az ; 

x yc = minimum allowable time interval depending on the sensitivity 
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(ii) When the current vertical separation is large and the relative 
vertical rate is closing, then the vertical closure time and the co- 
altitude range are computed and used for assessment. Thus, the 
criteria is given by: 

t v - - Az/Az < e yRA .AND. 

(29 

(Ar CA = Ar + x y . Ar < ^ CA .OR. |Az + | < y 

The threshold parameters are sensitivity level dependent and are 
given by Table 11. 

The RA altitude tests for an intruder which is already a threat 
are less stringent in order to retain an advisory until safe separa- 
tion is assured. The altitude test is considered passed as long as 
the threat is coverging in range. 

Table 12 summarizes the threat detection logic. 
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Table 11. RA Threshold Values 


Parameter 

Unit 

Sensitivity Level 

3 

4 

5 

6 

7 

Ar TA 

nmi 


.1 

.3 

1.0 

1.3 

6 hra 

o 

nmi /s 

.002 

.00278 

.00278 

.00278 

.004 

6 RCA 

nmi 

.3 

• 3 

.4 

.6 

.9 

®RRA 

s 

18 

20 

25 

30 

35 

T yc 

s 

35 

40 

40 

45 

48 

0 VRA 

s 

25 

30 

30 

‘ 35 

40 




8 z 

ft 

750 18000 > z. 

o 

850 29000 > z >18,000 

o 

950 Z v 29,000 

o 9 

" ‘ - — “ ~ • ‘ ' 1 " ' r 

0 

a 

ft 

340 z q < 10,000 ft 

440 18,000 > z > 10,000 

640 30,000 > Z Q >_ 18,000 

770 z > 30,000 

o — 


I 

I 
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Table 12. Summary of Threat Detection Tests 


Threat 

Range Test 

Altitude Test 

Comments 

Proximity 

Ar < 9. 

” Ar TA 

z 0 £ 15,500 ft 
|Az| £ 1,200 ft 

. Mode A only transponder 
. Mode C or S transponder 

Special TA 

Ar < 2*0. 

“ 4r TA 

|Az| £ 2.0 z 

. These tests are applicable to 
pop-ups because of unreliable 

Special RA 

Ar < 2«0. 

— Ar„ . 

RA 

velocity estimates. 

. Roughly 4 times the protection 
volumns. 

Traffic 

Ar £ 0 .AND. 

flr TA 

ir - lr ± 6 hta 

z Q £ 15,500 ft (Mode A) .OR. 

| Az | < 0 .OR. 

Ah TA 

. Range Divergent Case 

Advisory 

(1) 

minlt •T - '} < 0__. 
r* r — RTA 

T V — ®VTA 

. Range Convergent Case 

Resolution 

Advisory 

Ar < Ar,,. .AND. 
— RA 

Ar*A*r < 0 

n 

.(2) 

{|Az| £0 .AND. I Az I £0 } .OR. 
z z 

^ T V - 0 VRA ,AND * 

l4r CA - 9 RCA - 0E - l 4z+ l - V 

. Range Divergent Case 


min{x < 0__. 

r’ r — RRA 

. Range Convergent Case 


(1) and are the standard and modified range taus. 

(2) Az + is the projected vertical separation at the range critical times 

(3) Ar is the relative range at co-altitude. 























Resolution Advisory Selection 

An intruder which is declared a threat by the detection logic of the 
previous section is processed further by the Resolution Advisory Selection 
logic which is discussed here. The modules which are simulated in the digital 
simulation program are described; however, two major modules are deleted 
from the simulation program - coordination and multi-aircraft advisory logic. 

The coordination logic refers to the situation when both Own and the 
intruder are TCAS II equipped. In this situation, it is necessary that both 
TCAS systems work in a coordinated fashion, so that one does not generate a 
conflicting advisory with respect to the other. This is accomplished by means 
of one TCAS locking out the other; then, the locked out TCAS would behave 
similar to a TCAS I system. The coordination locking is performed through 
Mode S crosslink protocols. 

The multi-aircraft advisory logic coordinate the advisories due to two 
or more simultaneous threats. For example, "Climb" (caused by threat A) and 
"Descend" (caused by B) cannot be given simultaneously. Thus one of these 
must be changed. For example, if Own is flying level, then one of these may 
be such that descend or climb produce similar results in the vertical separation. 
Thus, "Descend" may be changed to "Climb" (it depends on the "don’t-care" flag). 

In the following sections, the rest of the Resolution Advisory Selection 
logic elements are discussed. These include Che sense selection. Own vertical 
modeling aspect, and advisory selection. 

Sense Selection . The maneuver directional sense (climb or descend - for. the 
resolution advisory) selection is performed only once for each threat. The 
sense is selected based on the projected vertical separation over the critical 
time period. The threat vertical profile is computed based on the constant 
vertical speed assumption. Own vertical is projected on the basis of 0.25g of 
acceleration (deceleration) to the nominal + 1500 fpm of climb or descent. 

Thus, the climb or descend sense selection is performed by actually predict- 
ing the altitude separation and evaluating against a separation threshold. 
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The threat and Own predicted altitudes are computed by the follow- 
ing expressions (see Fig 7 for Own computation): 


Threat: 


Zm = 


Z T + T Z T 


Own: 


z 0 + z 0 




Z„ = 


z o + r z 0 + °* 5 < t -t d ) a » t a + t d i T > V 


( 30 ) 


Here, 


z 0 + Tz 0 + °- 5 V 


+ . 


T > T a + V 


= Own pilot reaction delay time (nominally 5 sec) , 

t A = | z o- z G l z Max = acceleration time, 

• » 

a = z i iax Sign (z G - z) = maximum acceleration (k g) , 

Zq = desired vertical speed (+ 1500 fpm for climb and 

- 1500 fpm for descend) . 
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Altitude Rate 





(Desired Rate) 


Figure 7. Own Altitude Projection Model 
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Using the above vertical model, the climb/descend sense is chosen 
according to Table 13. Basically, the sense is selected on the basis of 
the worst predicted vertical separation over the critical time interval 
defined by x' (modified range tau) and T r (range tau) . 


Table 13. Climb or Descend Sense Selection 


(1) 

Compute target predicted altitudes at t and r': 
(T r ) and (t') 

(2) 

Compute Own predicted altitudes at t and x' , for Zq= 1500 fpm; 

■Sc <T r> “ d Z tc < T P 

(3) 

Compute Own predicted altitudes at and t', for =-1500 fpm, 

Z J D (T r ) and Z J D (t P 

(4) 

Compute the separation for climb sense; 


AzJ = min {[( 2 o C (T r ) - [z^rp - z+ (x')]> 

(5) 

Compute the separation for descend sense; 


fcj - min <t4(T r ) - (, r )], [4<rp - 2 + D 


(6) Select vertical sense by comparing the separations; 


climb 

(LSENSE = 1) 

if 

4z J =• 4z J 

descend 

(LSENSE = -1) 

if 

4z £ > 4z J 


T = Ar/Ar'; x' = - (Ar - 6r)/Ar', Ar' = min{Ar, - Ar . ,} . 
r r mm* 

$r = 0.247 nmi, Ar --- 0.00167 nmi/sec (10 fps) 
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If both senses provide equally acceptable vertical separation over the 
critical time interval, then the "don't-care" flag is set. This flag is used 
if other threats exist. It is noted that this selected sense is chosen once 
and only once for the duration of this threat encounter. 

Advisory Selection . A resolution advisory is selected against the 
threat using the sense selected by the previous section. In general, all 
the possible advisories are considered from weakest to strongest. The 
weakest advisory that satisfies the threshold, 6 a r (ALIM (ft)), against 
the threat at the closest approach is selected. The value of the RA 
threshold, ALIM, is given by Table 11. Table 14 shows weakest to strongest 
advisories. 

Table 14. TCAS Resolution Advisories 



Climb (Descend) Sense 

Vertical 

Speed 

Limit 

Don't Descend (Climb) faster than 2000 fpm 
Don't Descend (Climb) faster than 1000 fpm 
Don't Descend (Climb) faster than 500 fpm 

Negative 

Don* t Descend (Climb) 

Positive 

Climb (Descend) 


For example, if the selected sense is positive (climb) , then the 
projected separation is tested with the assumed vertical speed of - 2000 fpm. 

If the separation will not be achieved with this choice of vertical speed, 
then the next stronger (vertical speed of - 1000 fpm) speed is tried. This pro- 
cess is continued until the safe separation is achieved. Figure 8 shows this 
process for the vertical speed limit and positive advisory cases. It is noted 
that with this search sequence, either an advisory is found which is the weakest, 
or no advisory is found. If it is the latter case, then it is due essentially to the 


43 




detection logic delay or a sudden maneuver by the Target. (The intruder 
may have been a pop-up.) It is also noted that the above search procedure 
may have been time consuming. 

There are two exceptions to the above logic- (a) when the relative verti- 
cal rate is primarily due to the intruder and the vertical miss-distance is 
less than the resolution threshold, and (b) when Own is nearly level and both 
the current and projected vertical separations are within the threshold. In 
both cases an immediate positive advisory is issued. 

The descend sense is converted to negative if Own is proximate to the 
ground. If Own is near its climb limit (near the Own maximum altitude 
envelope), then the climb sense is converted to ”Don’t climb”. 

The above advisory selection procedure applies to intruders which are 
converging. If an intruder is not converging, then a negative (Don't climb 
or descend) advisory is issued. The reasoning is that an immediate positive 
advisory is not required. 

Advisory Evaluation Logjic. The advisory selection logic examines the 
projected separations of possible non-positive advisories systematically. 

If none are found which provide safe separation (ALIM), then the positive 
advisory corresponding to the selected sense is chosen without explicitly 
examining the vertical separation. Thus, the advisory evaluation logic is 
invoked to examine the projected separation corresponding to the positive 
advisory. If it is within the safety limit, then a flag is set. This 
situation can happen by a late maneuver by the intruder, by Own ? s failure 
to respond to an existing advisory, or by a late track acquisition. 

The flag (indicating that a safe separation is not achievable) is used 
to warn the pilot. He must resort to other means (such as visual acquisition 
or the ground ATC) of achieving a sufficient separation. This indicates a 
”panic” situation. 

In order to reduce the occurrence of such situations, the positive advis- 
ory is considered adequate if 100 ft of separation is achieved by the immediate 
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escape maneuver of a nominal 1500 fpm vertical rate. If an altitude crossing 
is inevitable, then the positive maneuver is assumed acceptable if it occurs 
before (modified range tau ) . 

Resolution Advisory Packed Discretes . Selected resolution advisory is 
packed into a twelve bit word. This is to facilitate the communication of the 
advisory to external devices such as a CRT display or audi-alarm in the 
cockpit. Table 15 gives the bit pattern definitions. The lower 9 bits are 
given; the upper 3 bits are reserved for horizontal advisories and are zero for 
the vertical advisories. It is noted that bit patterns corresponding to RA Map 
No. 6-10 are identical with bit patterns corresponding to 1 - 5, except Bit 6. 
Bit 6 signifies the climb/descend sense. 

Table 15. Vertical Resolution Advisory Bit Patterns 


1 I 

Packed Word 

RA Map No. 

Advisory 

100000000 

1 

Climb 

110000000 

2 

Don’t Descend (DDES) 

111000001 

3 

DDES/500 ^ 

111000010 

4 

DDES/ 1000 

111000011 

5 

DDES/2000 

100100000 1 (2) 

6 

Descend 

110100000 

7 

Don't Climb (DCL) 

111100001 

8 

DCL/500 (3) 

111100010 

9 

DCL/ 1000 

111100011 

10 

DEL/ 2000 

1 - — - ■ -■ 


(1) DDES/500 = Don't Descend faster than 500 fpm. 

(2) Bit 6 = sense sign bit (1 -*■ descend; 0 -*■ climb). 

(3) DCL/500 = Don't Climb faster than 500 fpm. 
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Ill 


BENDIX TCAS II SIMULATION PROGRAM DESCRIPTION 
Introduction 

Real time TCAS operation is very complex in terms of physical principals 
and computational functions. Most of the important aspects of the BX TCAS 
were covered in the previous chapter. A digital simulation model compatible 
with the CDTI applications is discussed in this chapter. 

Simulation models can be built at many levels of sophistication and fidelity 
depending on their applications. The BX TCAS model was developed with two basic 
requirements: (1) it be applicable for use in an active pilot-in-the-loop simu- 
lator; and (2) it be operationally accurate. The first requirement implies that 
the simulation must be able to run in real time along with other simulation ele- 
ments such as aircraft aerodynamics, engine, actuators and cockpit instrumentation. 
It also implies that the TCAS simulation model must be able to take traffic 
data, process them, and output the results in real time repetitively. Thus, 
it dictates a certain executive structure. 

The second requirement implies that important kinematic and dynamic 
characteristics are preserved. This means that the model must contain enough 
detail of the actual system without being overly complex. At the onset, it 
was decided to not be concerned with the details of radio transmissions. 

Thus, the TCAS simulation is based on the aircraft relative kinematics, since 
this aspect is the most important in the CDTI applications. 


The model was developed as an analysis tool in an off-line mode. How 
ever, the semi-real time executive, highly modular construction and the fact 
that it is written in Fortran (very portable) made it a very simple task to 
convert it into a real-time module. 

The simulation program is designed according to the over-all signal flow 
presented in Figure 9. The Traffic Generator is an external module which provides 
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kinematic information of Own and other traffic in Own’s vicinity. The Traffic 
Sensor block processes the input through geometry, measurement errors, estima- 
tion and surveillance scheduling modules to create (or update) the internal 
Own and traffic files. The CDTI block processes the Own and traffic files to 
generate display information. The CAS block makes threat assessments based 
on the same information to generate various advisories. In the following 
sections, macro aspects of the Traffic Sensor and CAS blocks are discussed 
in detail at module levels. The traffic generator, CDTI and CAS symbol 
generator modules are assumed to be external to the current simulation 
program. 


Executive Logic 

Figure 10 shows the BX TCAS executive logic flow. During each cycle 
time ( 1 sec interval). Own and Traffic information is passed to the simula- 
tion by means of an input common. Table 16 lists the necessary inputs. First, 
if the TCAS is operational (not on ground) , then file entries and parameters 
are initialized. This is the power-up mode. Afterwords, Own-dependent 
parameters and variables are computed and updated. Within the proximate traffic 
Do-loop, traffic data associated with each aircraft are processed to initiate, 
update or delete the internal traffic file entry. The basic sequential steps are 

(i) Check the surveillance schedule for this time period; 

(ii) If not scheduled, skip this cycle. Otherwise, compute TCAS 
measurements; 

(iii) If the report is invalid (probabilistic model) , skip this cycle. 
Otherwise, add measurement errors; 

(iv) Perform inverse transformation; 

(v) Check the acquisition or track status. If acquisition, update 
the track file entry and skip the rest; and 

(vi) If in the track region, update or initialize the position and 
velocity estimates and update the traffic file entry. 


The above steps are performed until each traffic element is exhausted. By 
this time, the traffic file is Initialized, updated or deleted. This part 

constitutes the sensor logic. 
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BX TCAS 



Figure 10. BX TCAS Macro Flow Chart 
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Table 16. List of External Input 


f Own Aircraft 

t 

Simulation time (sec) 

x, y, z 

North-east (nmi) and altitude above MSL (ft) 

V G 

Ground speed (kt) 


Altitude angles (rad) 

ITRGT 

CDTZ target identification number 

IWOW 

Weight-on-wheel discrete (=1= on ground) 

MANSEN 

TCAS sensitivity level 


(0 = off; 1-7 = manual; 8 = automatic) 

Traffic Data (up to 40) 

IDAC 

Uniquely assigned traffic identification 


number 

IXNSP 

Transponder type indicator 


(1 = Mode A only; 2 = ATCRBS; 3 = Mode S 

x, y, z 

North-east (nmi) and altitude above MSL (ft) 

NAC 

Number of Traffic in the Data Set 
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After the sensor part, certain housekeeping functions are performed. 

This includes timer count-down and file entry elimination of traffic which 
is no longer relevant. Then the collision avoidance logic is invoked. This 
module processes the traffic file corresponding to aircraft within the track 
region. The CAS logic results are stored in its own CAS file. 

The last major function is to schedule which aircraft (within the 
traffic file) needs to be interrogated in the next cycle. This function 
depends on the relative kinematics, acquisition or track status, or the 
threat status. Lastly, various output variables are extracted from the 
traffic file and stored in an output common. 

The above cycle is repeated again with a new set of external traffic 
data. The new set may contain new traffic. Traffic which was included in the 
previous cycle may not be present this cycle. The program is flexible to 
handle this changing traffic pattern. 

Figure 11 shows a more detailed flow chart. It has a very compact 
top-down structure, and all the computations are .performed by dedicated 
modules which include housekeeping functions. Even though it may be in- 
efficient compared to the in-line coding, this structure enhances the read- 
ability and maintainability of the software. 

Figure 12 shows the subroutine structure consisting of forty relatively 
small modules. These are grouped about the functional characteristics rather 
than the order of the calling sequence. Table 17 lists the major subroutines 
with short functional descriptions. There is direct correspondence between 
these descriptions and the TCAS operational descriptions given in Chapter 2. 

Major program commons are listed in Appendix A. Tables A.l through A. 7 
are the dictionary references between the Fortran names and engineering vari- 
ables and parameters. (Unfortunately, the Fortran compiler does not have cross- 
reference capability across the subroutines.) Transfer of variables among the 
subroutines is accomplished through these commons except for general usage 
subroutines and functions. The common variables are grouped according to 
functional definitions. Table 18 contains many common explanations which 
are useful. 
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ttxrt'AS 



^ End -Loop 



Figure 11. BX TCAS Executive Logic 
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Figure 12. BX TCAS Subroutine Structure 
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Table 17. Short Functional Description of Major Subroutines 


(1) BXINT 

(2) TRKOWN 

(3) CHKSMP 

(4) ADDFL 


Set system parameters and initialize variables. Zero out 
track file. Equivalent to "power-up" initialization. 

Perform Own vertical estimation based on the fine quantized 
altitude. Computes the transformation matrix, TBL, from 
0 and <j>. Computes dynamic parameters which depend only 
on Own variables. 

Looks up the file index corresponding to the AC ID No. 

If the aircraft is scheduled for surveillance, then ISURV 
flag is set. This routine is companion to SCHNXT (4). 

Adds aircraft to the track file if not yet filed. 


DRPFL : Deletes aircraft from the track file and the pertinent 

file elements are reset to zero. 


RPTVLD 

INVLD 


(5) FRDGMT 

(6) MEASMT 

(7) BCKGMT 

(8) COAST 
ESTMTN 


Resets invalid report counter, IRPT. 

Increments the invalid report counter, IRPT; it is compared 
with IRPTMX (nominally 4) and set deletion flag; if not, 
the aircraft is scheduled for the next surveillance 
period, i.e., one second later. 

These four routines are sensor track file management 
routines. 

Computes the forward geometry; i.e., the relative bearing b, 
the track region range limit and t ^ ie l°°k~ u P angle e. 

Computes measurement errors and the TCAS measured variables. 

Computes the backward geometry; i.e., local level north 
and east position. 

Prediction part of the estimation algorithm. 

Performs the estimation function including the filter 
initialization. It also computes next scheduled surveillance 
time (rounded up to second) . This routine calls two major 
subroutines ESTMSS (horizontal x-y tracker) and EFLTR 
(vertical tracker based on Level Switching Time) • 

This routine counts down CAS timers - 5 sec advisory counter 
and a 10 sec timer. Inactive threat is dropped in 5 sec and 
inactive traffic in 10 sec. When timers run out, various 
flags are reset. 


(9) CNTDWN 


Table 17 - Continued 


(10) CASSTS 

(11) DETECT 

(12) ADVSEL 

(13) SCHNXT 

(14) CASOUT 


This routine checks the Advisory status of tile candidate 
threat. It will find an empty CAS file slot and assigns the 
slot to the candidate if appropriate. It also cleans up 
CAS file if it is no longer a threat. 

Examines all the actively tracked aircraft against the 
proximity, traffic or resolution advisory conditions. 

Then creates a tentative collision avoidance file. 

This routine generates Proximate, Traffic and Resolution 
Advisories. Two major subroutines are called. These are 
SELSNS (select climb/descend sense) and SELADV (generates 
escape maneuver) . It also calls packing routine to pack 
output variables. 

Processes the next scheduled surveillance time for each 
aircraft in the traffic file. The flag, NXTS, is set if the 
aircraft is scheduled for the next one second interval. 

Stores output variables and also packs the BA discrete word. 



Table 18. Explanation of Program Common Contents 


1. /OWNTFL/ includes Own track variables including the Own inputs 
from external Own generation modules. The variables include 
position, altitude angles, body to local-level transformation 
matrix, altitudes and vertical estimate and initialization flag. 

/ITRGT/ includes CDTI target designation identifier (provided *by 
the pilot interface, weight-on-wheel status and TCAS operational 
status indicator) . 

2. /BNDXFL/ includes targets identification, various time data, true 
and measured range and bearing, true, measured and estimated x— y 
position and velocity. This and /ZTRKFL/ forms the sensor traffic 
file. The variables are allocated 20 elements so that the simulation 
program can track up to 20 targets in Own's vicinity. 

3. /ZTRKFL/ includes initialization flag, stored mode C altituducts 
and times, stored level switching variables and internal and external 
altitude and altitude rate estimates. These are used to implement 
the Level Switching Time vertical tracker algorithm. 

/ZWRKUR/ includes level switching time flag (temporary) and other 
variables which are used as temporary work memories. 

4. /WOKKVR/ includes indicators and flags for the executive logic, 
temporary position variables and sensor constants, parameters and 
dynamic thresholds. 

5. /CASFIL/ is the collision avoidance logic threat file. Up to 5 
threats are accomodated each cycle (no multi- threat logic, however) . 
The common includes number of declared threats. Traffic file index 
(identification), RA, TA and PA counter and status, 10 sec timer, 
and threat related variables such as time to CPA, relative x-y-z 
position at CPA, reference vertical speed for escape maneuver, RA 
packed-word and RA text. This common needs to be accessed for CAS 
output construction depending on the external device requirements. 

6. /CWRKVR/ includes number of candidate threats, temporary /CASTIL/ 
index, RA capability flag. Own and Target (Mode S only) sensitivity 
index, PA, TA and RA temporary flags and temporary CAS timer, 
vertical current and projected separations. 

/CWRKV2/ is supplemental to /CWRKVR/ and includes temporary RA 
packed-word, various flags and projected vertical separations. 

7. /CASPAR/ contains all the necessary collision avoidance threshold 
values. Some of these are constant. These are dynamically deter- 
mined each cycle time. 
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In the following sections Sensor and Collision Avoidance Logic modules 
are discussed in detail. 


It is advisable for readers to obtain the program listing - ETCAS II.VLD - 
from Dr. R. L. Bowles or Mr. D. Williams of NASA/Langley. The program is 
very £asy to read and contains detailed engineering comments. 
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Sensor Module 


The TCAS sensor module contains twenty subroutines and includes the 
following major components: 

(1) Computation related to Own variables; 

(2) Traffic file management routines; 

(3) TCAS geometry and measurements; 

(4) Traffic aircraft position and velocity estimation; and 

(5) Surveillance (interrogation) scheduling. 

These are discussed in detail using tables, flow charts, and equations in 
the following sections. 

Computation Related to Own Variables The major routine is TRKOWN. In 
addition to the Own related computation, it is used to initialize or reset 
variables for the 1 sec computation cycle. This is the first subroutine to be 
called by the BXTCAS executive. Table 19 summarizes the computation in proper 
sequence. The following remarks apply to the item numbers in Table 19. 

Item (3) - Initialization is performed by the VFLTIN subroutine as follows 



The estimation update is performed by the VFLTSS subroutine using the 
standard alpha-beta tracker algorithm as follows: 


z 0 = Z 0 + z o> 

~ m _+ 
0 “ 0 0 » 


2 o - *0 + “O' 

l a - l a + 




(32) 
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Table 19. Own Related Computation (TRKOWN) 


(1) Transfer Own input (t, x, y, z, V , <j> , 0 , ip ) to a separate 

G 

TCAS common called /OWNTFL/. Compute radio altitude. 

(2) Using <j>, 0, and i|> compute Tg^ . See Eq (19). 

(3) Initialize (Subroutine VFLTIN) or update (Subroutine VLFTSS) 
Own altitude and altitude rate estimates. 


(4) Compute the acquisition or tract region related variables 
(DHMTRK, RLIM, STMAX) . See Eqs (3,5,6) 


(5) Determine Own sensitivity level index (LVLOWN) depending on 
radio altitude (RALT), baro altitude estimate (Z0M(1)), and 
pilot manual select (MANSEN) . See Table 4. 


(6) Estimate altitude above ground using radio and baro altitudes. 


(7) Compute collision avoidance thresholds, ZTHR and ALMT. See 
Table 9. 


(8) Reset variables NORA (No Resolution indicator ) , NCAND(IO) , 
INTENT, INTHR, LVSLOK, LDCFLG, and LADNOK. 
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where aand Rare equal to 0.4 and 0.15, respectively. 


Item (6). Because most radio-altimeters are valid for readings below 
2500 ft, the height above ground level is estimated only where radio 
altitude is less than 2500 ft. The estimate is given by the baro- 
altimeter based altitude estimate minus the radio-altitude. 


Traffic File Management Routines There are four routines in this cate- 
gory - ADDFL, DRPFL, RPTVLD, and XNVLD (CHKSMP is discussed later). Each 
is discussed below. 

The ADDFL routine goes through the traffic file list, IDF (see common/BNDXFL/) . 

If the input aircraft identification corresponds to one of the IDF's, then the 
corresponding index is returned. If the input identification is not included, then 
an empty file is searched, and the index is returned. If an empty file is not found, 
then INDEX is set to -1 to indicate the status. When the index is found, then 
the acquisition or track status and the transponder type are stored. 

The DRPFL routine is essentially the reverse of the above process. If the in- 
put aircraft is no longer within the serveillance volume, then the aircraft 
identification is deleted from the list, IDF, and the corresponding file ele- 
ments are reset. 

The RPTVLD routine is called when a valid surveillance report is received. 

In this case, the IRPT counter corresponding to this aircraft's file index is 
set to 0. 

The INVLD routine is called when an expected surveillance report is ngt received. 
The routine performs the following computations: 

(1) Increment the invalid report counter, IRPT, by 1; 

(2) If IRPT is greater than 3, then drop further surveillance effort for 
this aircraft; or 

(3) If IRPT is less than or equal to 3, then schedule the surveillance 
interrogation for the next operating cycle by setting TNXT(INDEX) 
to 1 sec. 
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The corresponding program listings should by consulted. Because of the 
file management nature of these routines, the logic is complex but otherwise 
straight forward. 

TCAS Geometry and Measurement There are three subroutines in this cate- 
gory - FRDGMT, MEASMT, and BCKGMT. These are discussed below. 

The FRDGMT routine performs forward geometry computation. The north-east- 
down (NED) target relative position is transformed to body referenced posi- 
tion using the T LB transformation. See Eq (10) . Then the bearing and look-up 
angles are computed using Eq (11). The look-up angle is used to check for 
antenna vertical coverage. Additionally, the bearing dependant maximum track 
range (RNGTRK) is computed using variables computed in TRKOWN and the bearing 
angle. Equation (4) is used for this purpose. It is noted that the range is 
computed in the executive (BXTCAS), because it is independent of the orthogonal 
transformation. 

The MEASMT routine computes range and bearing errors (assumed to be zero mean 
white noise with 75 ft and 1 deg standard deviations, respectively). These 
errors are added to true range and bearing to form the TCAS measurements. 

It is assumed that the input altitude contains the baro-altimeter error char- 
acteristics.* Therefore, this routine simply quantizes the input altitude to 
generate the Mode C altitude report according to the following formula: 

Ih = Int[z T +0.5 q)/ql; q = 100 ft. (33) 

For a Mode A target, Ih is assigned a large number (1270) (an altitude 
of 127,000 ft). 


The BCKGMT routine performs the inverse transformation, i.e., the NED re- 
lative position is obtained from measured range, bearing and altitude. This is 
the reverse of the FRDGMT computations. 


*It is noted that that the current program contains reference to the altitude 
scale factor error (SFT) and the high frequency noise (SIGZ); therefore, SFMX 
and SIGZ must be assigned 0 to affect the above requirements. 
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When the target transponder has only Mode A capability, the altitude 
measurement is not available. Thus, in this case, the exact inverse trans- 
formation cannot be obtained. (The Mode A target can only generate TA and 
PA.) The problem is side-stepped by assuming that (1) the target is at co- . 
altitude and (2) Own pitch and roll angles are zero. With these assumptions, 
the Mode A target's horizontal position is given by 

Ax m = Ar cos + Ab) , 
m 

(34) 

Ay m = Ar sin (^ + Ab) , 

Where 4> is the Own heading angle. This procedure is recommended by the draft 
TCAS MOPS 12]. 

When the target transponder is Mode C (ATCRBS) or Mode S, then the more 
exact transformation is obtained by following Eqs (12) through (17). A small 
modification is added to prevent a singularity problem caused by measurement 
errors. When the relative range and altitude are similar, then the additive 
noise may make range smaller than the relative altitude. This causes the 
singularity problem in the above inverse transformation. This is avoided by 
redefining the range as 

Ar m = Az + 300 ft . (35) 

! 

It is noted that this routine uses the same transformation matrix 
used in the FRDGMT routine. In reality, the computation performed by the 
FRDGMT and MEASMT routines are not part of TCAS system; this part is done 
via various RF activities and associated processes. Therefore, in order 
to increase the simulation fidelity, the transformation matrix used in 
BCKGMT must be computed from the measured <*», 9, and ^ rather than the true , 
0 and In many simulation environments, the measured values as well as 
the "measured" transformation are available in the navigation module; there- 
fore, these may also be input and used rather than the true values. 

j 

| At this stage, the measured NED positions are obtained and the corre- 

sponding track file elements are stored. These are used by the next task 
to generate estimates. 
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Position and Velocity Estimation The estimation function based on the 
TCAS sensor measurements is performed by two subroutines - ESTMTN and COAST. 

The ESTMTN subroutine is the estimation executive and takes care of all esti- 
mation function except the prediction part which is performed by COAST. 

The COAST routine performs the 1 sec prediction for targets which are 

within the track region according to the following formula: 

^ A A a A -A 

Ax = Ax + Ax; Ay = Ay + Ay (36) 

If the target is Mode C or Mode S, then the external altitude is also coasted 
by a similar equation: 

A A A 

Z EX = Z EX + Z EX * < 37 ) 

The COAST routine is called by the BXTCAS executive if: 

(1) The individual target was not scheduled; or 

(2) There is a failure in surveillance caused by either the reliability 
test or antenna shadowing. 

For the BXTCAS, the former is usually the reason, because targets are usually 
scheduled with longer than a 1 sec surveillance interval. 

The ESTMTN executive performs the following three tasks: 

(a) Process altitude input; 

(b) Process horizontal input; and 

(c) Compute next surveillance time based on the latest estimates. 

These are performed according to the computer flow chart depicted in Fig. 13. 

First, the target transponder flag is checked. If the target is Mode A, then 
the estimate is set to the input value (which is set to 127,000 ft in MEASMT) ; 
otherwise VFLTR is called to process further. The VFLTR routine is explained later. 

Next, the target’s track status is checked. There are four possibili- 
ties based on the previous and current status: 
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Figure 13. Estimation Executive (ESTMTN) 
Flow Chart 
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(1) in the acquisition region; 

(2) sudden track region (pop-up) ; 

(3) transitioned from acquisition to track status; and 

(4) in the track region. 

In Case (1) the estimates are set to the measurements (this is neces- 
sary for initialization purposes) . The last valid report time, TLST, is 
set to the current time; the next surveillance time, TNXT, is set to 8 sec; 
and the track status (IDM) is noted. 

Case (2) represents a peculiar dynamic situation. Because the track 
region is contained in the acquisition region, the targets in the traffic 
file are expected to "transition" from the acquisition to track (and back 
to acquisition and then disappear) . Because encounters for simulation 
scenarios may begin with given traffic patterns, and/or because targets may 
have been in the antenna shadow, targets may appear in the track region with- 
out being identified in the acquisition region. Therefore, this situation 
requires a special logic. The target is assigned to be in the acquisition 
traffic. Thus, the same actions are taken as in Case (1) except TNXT is set 
to 1 (this prompts the surveillance during the upcoming 1 sec cycle time) . 
Additionally, the pop-up counter, NPOP, is set to 4 so that for the next 
four cycle periods the target is interrogated. 

In Case (3) , the target has transitioned from the acquisition to track 
regions in a conventional way. The estimates are initialized in the ESTMIN 
routine using the last two measurements as follows (sequential order of 
computation must be kept) : 

4 

Ax = (Ax m - Ax) / (t - t LgT ); and (38) 

Ax = Ax , 
m* 

A 

^ ere » 4x in the velocity equation contains the last valid report time 
(TLST) measurement. The Ay equations are analogous. The valid report time 
and the track status are updated. 
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In Case (4), the target has been In track region; thus, the "steady 
state" algorithm (Eq (20) and Table 3) is used in ESTMSS. There is one 
exception. The prediction is performed for a 1 sec interval only, since 
the COAST routine has been performing the prediction for other sampling 
periods. 

Targets which are applicable to Cases (3) and (4) are further pro- 
cessed to compute the next surveillance time (t^^) based on the updated 
estimates. For this purpose, targets are assumed to be Mode S equipped and 
a modified Eq (8) is used, i.e.. 


At T (t NXT ) = Max (1 sec, min (t^, t VT , 8}} 


Here, 


t „ = the number of 
HT 

horizontally; 
tyf ■ the number of 
vertically. 


seconds it will take the target to move 1,000 ft 
and 

seconds it will take the target to move 200 ft 


Furthermore, if the target range is less than Ar g (1.65 nmi) , then 
C NXT * s set t0 * sec * Als 0 * if the target is identified as a preliminary 
threat, then t^^, is set to 1 sec by the CAS logic. 


The vertical estimation is performed by the ZFLTR routine which implements 
the Level Switching Time (LST) tracker algorithm. Figure 14 depicts a macro 
flow chart. Inputs are the traffic file index (INDEX), system time and 
Mode C altitude. Outputs are the external altitude and altitude rate estimates 

4 

(z EX , z E x^ contained in the /ZTRKFL/ common. The logic is complex due to 
the 100 ft quantization of the Mode C altitude report. The situation is de- 
picted by Fig. 15. 


First, the altitude estimates (and host of other internal variables) are 
initialized, if not yet done. The DTCTL0 routine is next invoked to see 
whether a new altitude level was attained. If new level switching was detected. 
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Input: INDEX, TIME, MODEC 


: Initialize 


: Detect Level Switching 


: Compute Interval Estimates 


: Fine tune interval estimates 
and compute external 
estimates 


Figure 14. Vertical Tracker Algorithm Macro Flow Chart 
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then LSTSQR is called to calculate the altitude and altitude rate rough esti- 
mates. Finally, the rough estimates are tested for consistency with respect 
to the measurements. Essentially the following computational steps take 
place. Reference [1] should be consulted for further detail. 


The DTCTLO routine performs the level switching time detection in two 
ways. One is for cases where the average sampling period is slower than 4.5 
sec or the last valid report time was more than 4 sec ago. The other case is 
for the more frequent sampling case. For the first case, average altitude and 
time are computed by 


Z L - — ti\(t LST>1 ) + iV’t.st ^ 1 ; and 

C L = 2 ^LST,1 + t LST,2^ 


For the second case, they are computed by 


Z L = ^LST.P 5 atld 


) * t 

LST, v LST, i 


^ ere » ^*"LST,i^ and ^LST i are l a ^est five valid stored Mode C reports 

and corresponding times. If the corresponding altitude level, L, given by 


L = Int [z L + 50) /100] , 


(40) 


is different from the previous level (stored L) , then the level switching 
is declared, and z L , t L and L are saved in a 3-tier shift registers (i.e., 
current and previous two) . It is noted that Eqs (39) represent the three- 
out-of-five rule. 
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If the level switching is detected by the above logic, a flag (LOSWCH) 
is set to 1, and the filter status indicator, ICZ, is incremented by 1. If 
not, LOSWCH is set to 0. Additionally, if the current and the one previous 
to the last levels are the same, the ICZ is set to 1 indicating a level 
flight. 


Rough or internal altitude and altitude rate estimates are obtained by 
the LSTSQR routine when LOSWCH is 1. This is accomplished in three ways 
according to the ICZ indicator as follows: 


(1) When ICZ = 1, then 


Z IN _(Z L,1 + Z L,2 )/2 and Z IN = 0 * 


(41) 


(2) When ICZ = 2, then a linear equation is used 

Z IN = Z L,1 and Z IN =(Z L,1 " Z L,2^ (t L,l“ t L,2 ) 5 ° r (42) 

(3) When ICZ >^3, then a three-point least squares formula is used 

(43) 


pj 

1 

[4 

+ A 2 -(A 2 + A 3 ) 


Z L,1 + Z L,2 + Z L,3 

r 

N •> 

H 
, 25 

= D 

1 

1 

/-N 

> 

ho 

+ A 3 ) 3 


A 2 z L,2 + A 3 z L,3 


where 


A„ = 


fc L,2 “ A 3 = fc L,3 “ fc L,l * 


and 


(44) 


D - 2 [A 2 - A 2 A 3 + A 2 ] . 

In the above, (z T . , t T .) are saved "average" altitudes and times with 1 be- 

Lly i L, i 

ing the latest and 3 being the oldest. 
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The internal estimates, z^ and z^, are fine tuned by feedback laws 
in the CONSST subroutine, as follows. First, the time interval spent at the 
new altitude level is tested for consistency. The current time (t) minus 
the time the latest level switching was detected should not exceed either 
the expected time duration ( 100 /|z^|) or the average duration (t^ ^-t^ 3 ) / 2 ) ; 
thus 

t - t^ ^ : 100 /|z^| (expected level occupancy time) 

t - t L 1 ; (t^ j) - (t^ j )/2 (average level occupancy time). 

The actual logic is modified by tolerance factors for noise protection pur- 
poses. If t - t - exceeds either of two quantities, then a level flight is 

Ljj ± 

declared with proper actions. The idea is that if the altitude reports have 
not been changed for a long time duration, then the aircraft must have leveled 
off. 


If the above test is passed (aircraft is assumed to maintain a steady 
altitude rate) , then a feedback law is used to fine tune the internal esti- 
mates. The average prediction error is computed by 


Z i 100 Ih m^ fc LST, i^ * Z IN + ^LST,i " t L,l )z IN ^ » 


z =7 z, . 

av 5^1 


(44) 


Because the above error includes + 50 ft of basic uncertainty due to the 
100 ft quantization, it is modified by 


z - 50 if z > 52 , 

av av — * 


z =<{ 0 

av 


if |z av | < 52 , 


z +50 if z„ r < - 52 

av av — 


( 45 ) 
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This error is used to modify the rough estimates according to 


Z = 7 + Ot * Z 

Z IN IN av 


Z IN " Z L,1 + ^ Z IN " Z L,1^ " ’ 


’ Kb + ’ 


where 


[[ x ]] M ^ x is limited to the maximum value M in magnitude. 

Terms in these equations are 

z., = 25 ft = maximum allowable altitude tuning, 

M 

z^ = 8 fps = maximum allowable altitude rate tuning, 

a = 0.632 = altitude error gain, and 

B = 0.25 = altitude rate error gain. 

After the rough estimates are fine-tuned, the external estimates are 
computed as follows: 


Z EX " Z IN + (t " ^..l* Z IN ’ 


Z EX Z IN * 


Equation (47a) signifies that the internal altitude estimate, z IN , is 
computed and referenced at time t L 1 (the last time level switching was detected) 
Therefore, the second term, (t - t L ^ z IN accounts for the altitude rate up 
to the current time, t. 
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It is noted that the ZFLTR routine is invoked even though the target 
is still in the acquisition region (horizontal components are not updated 
in this region). There are two reasons: (1) altitude error is independent 
of range; and (2) long time delays in the altitude rate estimate need to 
be minimized. 

Surveillance (or Interrogation) Scheduling The surveillance scheduling 
function is performed by two subroutines - SCHNXT and CHKSMP. The SCHNXT 
subroutine identifies the target which requires the surveillance for the up- 
coming cycle period, and CHKSMP checks the scheduled list. These are the last 
and the first traffic sensor routines in any given cycle time. 

The SCHNXT routine examines if the pilot selected any CDTI target.* If 
so, the selected targets t^^ (TNXT) is set to 0. All the pop-up targets 
are treated the same way (NPOP counter is decremented by. 1) until NPOP becomes 
0. Then it is no longer a pop-up. 

The surveillance time counters (t^T^ com P ute ^ by the ESTMTN routine 
for all other targets are decremented by 1. If they are greater than 0, then 
the corresponding target is not scheduled. (This is indicated by NXTS = 

-|IDF| .) If the counter is between 0 and -4, then the corresponding target 
is scheduled. (This is indicated by NXTS = + [ IDF | . ) If the counter is 
less than or equal to -5, then the corresponding target is deleted from the 
traffic file, because it is no longer in Own's vicinity. 

The CHKSMP routine determines which target is not scheduled for the 
surveillance transaction. This is accomplished by examining the input air- 
craft identification number (IDENT) with the ones in the NXTS list. There 
are two cases to be considered: (1) IDENT is not in the traffic file or 

is already scheduled; and (2) IDENT is contained in the NXTS list. In Case 
(1) , the rest of the sensor simulation computation needs to be performed. In 
Case (2) , further computation is not necessary for this target except for the 
COAST (position prediction) routine. 

- ' 

This option is not a TCAS system requirement; it is added for CDTI research 
purpose. 
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Collision Avoidance Logic Module 

The collosion avoidance logic module contains nearly 20 subroutines 
which can be grouped into the following major components: 

(1) Threat detection; 

(2) Counter and housekeeping routines; 

(3) Climb/descent sense selection; 

(4) Advisory selection algorithm; and 

(5) Advisory packing and outputing. 

Before each component is discussed in detail, it is advantageous to 
examine the CAS executive logic to gain the over-all logic structure. 

Fig. 16 shows the vertical CAS logic executive macro flow chart and is 
a lower portion of the BXTCAS macro flow chart shown in Fig. 11. 

First, the CAS operational status flag (NORA) is checked. If it is 
1 (or up) due to pilot selection or the Own altitude being too low, then 
the entire CAS logic is skipped. The CNTDWN subroutine is then called to 
update counters and timers for each threat in the CAS file. If there is 
no candidate traffic to examine, then the rest of the logic is skipped. 
The candidate traffic is defined to be aircraft which are in the track 
region during the current sensor cycle. The traffic file indecies are 
saved in the NCAND list. 


For each candidate in the NCAND list, DETECT, CASSTS, and ADVSEL rou- 
tines are invoked. The functions of these routines are threat detection, 
threat detection status update and advisory (or escape maneuver) selection. 
After all the candidate traffic are cycled through, the CASOUT routine is 
invoked to pack advisories for output purposes. 

The internal CAS file elements are dimensioned five so that up to 
five threats can be accommodated. 
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Threat Detection Logic The DETECT subroutine performs the detection 
logic computation. This routine contains all three threat situations - 
proximity, traffic and resolution Advisory (PA, TA and RA) tests. The logic 
and computational steps are as described before in chapter III. Table 20 sum- 
marizes the top-down computations performed by DETECT. References are made 
to tables and equations so that the details can be supplied. The following 
notes correspond directly to the item numbers appearing in Table 20. 


Note (1) : Temporary flags LPA, LTA and LRA are used to track the 

status. They are defined as follows: 

Reset LTA (LRA) = 0 

Range test pass LTA (LRA) = 1 

Altitude test pass LTA (LRA) = LTA + 10 (LRA+10) 

Therefore, if both range and altitude tests are passed, 
then the flags would have a value of 11; otherwise they 
would be 0, 1 or 10. 


Note (2) : The target sensitivity level is computed only for 

Mode S. The combined sensitivity (LVLINT) is given by 

LVLINT = min { LVLOWN, LVLINT}, 

where LVLOWN and LVLINT are computed according to Table 
4. The level index, LVLNDX, is given by 
LVLNDX = LVLINT- 2 

LVLNDX is used to index the altitude sensitive CAS parameters. 
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Table 20. DETECT Subroutine Computational Steps 


(1) Reset CAS temporary flags (LPA, LTA, LRA = 0) 

(2) Compute TCAS sensitivity level and index (LVLINT, LVLNDX) (Table 5) 

(3) IF Mode A target, perform Mode A PA tests. GO TO Step 11. 

(4) Perform PA test for Modes C and S. 

(5) Perform special TA and RA tests, IF it is a pop-up. GO TO Step 11. 

(6) Compute range and range-rate (Tables 6 and 7) 

(i) perform divergent TA and RA range tests, or 

(ii) perform convergent TA and RA range tests 

IF both TA and RA range tests fail, GO TO Step 11. 

(7) Compute relative altitude and altitude rate. 

(8) Perfora TA altitude test. (Table 7) 

(i) current altitude separation small, or 

(ii) current altitude separation large 

(9) Compute vertical miss distance (VMD) (Table 10) 

(10) Perform RA altitude test 

(i) current vertical separation small [Eq (28)], or 

(ii) current vertical separation large lEq (29)] 

(11) Check if any of the PA, TA or RA tests are passed by testing LPA, LTA 
and LRA flags. If so, set the next surveillance flags (NPOP and TNXT) . 

(12) EXIT 
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Note (3) : 


As mentioned previously, the PA test for Mode A target 

A 

is given by Ar <_ 2 nmi . AND . z q — ^-5,500 

The traffic test is not performed for a Mode A target, 
since PA and TA for Mode A are essentially for pilot 
warning purposes, and the PA range test contains the 
TA range test. 


Note (A) : The PA test for Modes C and S targets is given by 

Ar < 2 nmi . AND . |z Q - z T | < 1200 ft 

Note (5) : These are special tests unique to this simulation. When 

the target is known for less than 24 sec, then it is treated 
as a pop-up, and the following test applies. 

| Az 1 < 2* 0 Z . AND . Ar < 2* Ar TA =^>LTA = -11 

|Az| < 2* ez . AND . Ar 2* Ar^^LRA = -11 

The rationale is that during this initial period it 
could be that the TCAS has possibly two surveillance 
data points about this target; this is not enough data 
to ascertain important estimates. The thresholds are 
taken to be twice the nominal, and the negative signed 
flags warn the pilot to look out for the traffic (VFR 
acquisition) . 

Note (6) : The vertical miss-distance, VMD (Az ) , is computed by the VRTMD 

subroutine. 

Additional Note: The TA and RA test thresholds are given in Tables 7 

and 9 respectively. Within the program, values corresponding 
to the sensitivity levels of 3, A, 5, 6, and 7 are stored, and 
these correspond to the level indecies of 1 through 5. 
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Counter and H ousekeeping Routines Two subroutines - CASSTS and 
CNTDWN - are involved in this category. Each is explained below. 

The CNTDWN routine counts down each of the 5 sec advisory counters 
(IPACNT, ITACNT and IRACNT) , the RA counter (NSTS) , and the 10 sec timer 
(TMCNT) . The 5 sec and RA counters are divided by 2 (i.e., right-shift 
by 1 operation) and the timer is decremented by 1. The results are that 
the "inactive threat" is dropped from the display in 5 sec and becomes 
dormant for 5 more seconds until the 10 sec timer runs out. When this 
happens, the CAS file for that traffic is cleaned and readied for other 
threats. The RA counter is used to prevent an on-again off-again Resolu- 
tion Advisory. 


The CASSTS routine monitors the CAS status by performing the follow- 
ing functions: 

> 

(1) Assign a file slot if it is a threat; 

(2) Test against the previous threat status; and 

(3) Clean up if no longer a threat. 


Table 21 shows the top-down computational flow for this subroutine. The 
following notes correspond to the item numbers in the table. 


Note (1): If the aircraft is an RA threat, then it is automatically 

a TA threat which implies that it is a PA threat. 

Note (2) : The IDCAS list contains the index number of the aircraft 

in the traffic file, /BNDXFL/ , so that the accessing of 
the traffic file for a threat is direct. 

Note (4) : If all the entries in the IDCAS list are full, then the 

further processing of aircraft is held until the next cycle 
time. A better way is to bump a lower ranking threat, i.e., 
if the aircraft is an RA threat, then the PA or TA threat 
in the CAS file should be deleted and the slot given to the 
RA threat. 
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Table 21. CASSTS Subroutine Computational Steps 



(1) Set LTA = 11 if LRA = + 11 

LPA = LRA if LTA = + 11 

(2) Look through IDCAS list for this aircraft. 

(3) IF not in the list and non-threat, RETURN. 

(4) IF new threat, look for a CAS file slot. 

IF found, assign to this aircraft; OTHERWISE RETURN. 

(5) Set timer and counters 
TMCNT = 10 

NSTS, IPACNT, ITACNT , IRACNT = 16 

* 

(6) Check against previous status and set flags, IPAFLG, ITAFLG and IRAFLG. 

(7) IF the counters are all zero, clean-up the file slot. 

(8) RETURN. 
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Note (6): This is done by the subfunction LADSTS. For example, 

IRAFLG (N ew ) * U«l < IEA CNT (Kew) , IRAFLG (01d) , 16). 

Functional evaluations are defined by the following 
table with explanations. 


Table 22. Functional Evaluation of LADSTS 


IRACNT (New) 

IRAFLG (01d) 

IRAFLG (New) 

EXPLANATION 

non-zero 

-1 

1 

continuing 

threat 

16 

0 

-1 

new threat 

0 

1 

0 

old threat 


IRAFLG > 


= -1 signifies that this aircraft is a threat, 


7 (New) 

therefore an RA must be generated (but only once) . If it 
is 1, then this is a continuing threat, i.e., an RA already 
exists. If it is 0, then the aircraft was an old RA threat. 
Thus, the old RA must be deleted. 


It is noted that the old logic contained the so-called 
2-out-of-3 counting rule, i.e., a threat is not declared 
(or nullified) if not done so in two out of the latest 
three cycles. This rule made the old versions of CASSTS 
and CNTDWN routines very complex. 


82 













Advisory Selection Mini-Executive (ADVSEL) The climb/descend sense 
selection, advisory selection algorithm, and advisory packing modules are 
controlled by a mini- executive called ADVSEL. It examines the CAS status 
flags (computed by the DETECT and CASSTS routines) and calls appropriate 
subroutines depending on their status. Figure 17 shows a detailed computa- 
tional flow chart of ADVSEL. An explanation follows. 

First, the RA flag is tested. (JDX is the CAS file index for this 
threat). If it is positive, then it is a continuing RA threat, and pre- 
sumably an RA has been generated; therefore, exit. If the flag is zero, 
then it was an RA threat previously; therefore, downgrade it to a TA threat 
and test further. If the RA flag is negative, then it is a new RA threat; 
therefore, an RA must be generated. Now, test LRA (temporary RA flag genera- 
ted by the DETECT routine) . If it is —11, this signifies a special pop-up; 
therefore, pack a special RA by calling SPCLRA subroutine and exit. If 
LRA is 11, then this is a "regular" RA threat; therefore, determine the 
climb/descend sense by calling SELSNS and generate an escape vertical 
maneuver by calling SELADV. If a satisfactory maneuver was not found 
(NOMAN = -1), then pack a special RA by calling SPCLRA. Otherwise, pack 
a "regular" RA and exit. 

If the aircraft is not an RA threat, then the TA flag (ITAFLG) is 
tested. If it is positive, then it is a continuing TA threat; therefore, 
exit. If it is 0, then it was a TA threat in the previous cycle. There- 
fore, downgrade it to a PA threat, and perform further tests. If ITAFLG is 
negative signifying a new TA threat, then pack a TA and exit. 

The proximity advisory portion is entirely analogous to the TA logic. 
Major subroutines called by the ADVSEL mini-executive are SELSNS, SELADV and 
various packing routines. These are explained below. 

Climb/Descend Sense Selection (SELSNS) As mentioned previously, the 
CAS logic chooses the climb/descend sense only once per RA encounter, and 
the chosen sense will remain in force until the threat is no longer. Basi- 
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ADVSEL 





Figure 17. ADVSEL Detailed Flow Chart 
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cally, the following computational sequence takes place. Threat altitude 
is projected to critical times (defined by the range closure tau's) by 
assuming the current altitude rate is maintained. Own altitude is 
projected to the same critical times by assuming + 1500 fpm of nominal 
vertical rate, 8 fpss acceleration to attain the nominal rate, and 
a 5 sec maneuver delay time, respectively. Using these projected altitudes, 
the projected altitude separations are computed. These are compared with 
each other and with the separation threshold to determine the sense. 


Table 23 shows the top-down computational flow for the SELSNS subroutine. 
The following notes correspond to the item numbers in the table. 


Note (2): The range and modified range tau's are given by Eq (25) 

with the range rate limited to RDTHR (10 kt) for the 0 
divide check. The tau's are limited by t^ c (TVPCMP) from 

above. The modified tau's are limited to 10 sec from below. 


Note (4): Projected altitudes are computed using Eq (30) which is 

implemented as the ZPROJ subfunction. The projected altitudes 
are limited to the field altitude. For computation and deter- 
mination of the sense flag (LSENSE) , see Table 10. 

Note (5): The "Don't-care" flag (LDCFLG) is set to 1 if both climb and 

descend satisfies the safe separation criteria ALMT ( 0 a ) . This 
flag would be used in the multi- threat logic. 


Resolution Advisory Selection (SELADV) The software module for select- 
ing a proper escape maneuver (Resolution Advisory) is very complex due to its 
logical rather than computational nature. The main idea of how this is done 
was explained in Chapter II. The procedure is explained further from the simu 
lation program view point. 


Figure 18 shows the SELADV subroutine tree. It shows two major branches. 
One is for generating a negative (or vertical speed limit) advisory, and the 
other is for a positive advisory. Each of the subroutines are discussed in the 

following paragraphs. 
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Table 23* SELSNS Subroutine Computation Steps 


(1) Reset CAS logic flags (INTENT, INTHR, LSENSE, LDCFLG, LVSLDK, LADNOK) 

(2) Limit the range and modified range tau's and set the lower altitude 
bound and the delay time. 

(3) IF the tau's are shorter than the delay time, simply project the threat 
and Own altitude and compute the separation; GO TO Step (5) 

(4) OTHERWISE 

Compute Own projected altitudes assuming +I500fpm 

Compute Own projected altitudes assuming -ISOOfpm 

Determine worst case separations for climb and descend 

(5) Determine the sense (LSENSE) comparing the two separations 
Assign second choice separation 

Set "Don’t-care" flag (LDCFLG) if second choice is satisfactory. 

(6) RETURN 



Figure 18. Resolution Advisory Selection Subroutine Tree 
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Figure ly shows a detailed computer flow chart for the SELADV subroutine. 
First, the threat altitude rate is tested. If its magnitude is less than 
16.67 fps (1000 f pm) , then the current altitude separation is tested against 
the safety limit (ALMT) also considering the selected sense (this is done by 
the CHKPRJ subroutine shown in Fig. 20). If the current separation is safe 
(indicated by the in-threshold flag, INTHR, being 0), then negative advisories 
are examined by invoking the TRYVSL subroutine. 

If the threat altitude rate exceeds 1000 fpm in magnitude or the current 
separation is not safe (from the previous test) , then the vertical miss dis- 
tance (VMD) is tested against the safety limit by considering the selected sense 
If it is within the threshold, or the Own altitude rate exceeds 10 fps (600 fpm) 
then negative advisories are examined. Otherwise, the positive advisory cor- 
responding to the selected sense is assumed (this is achieved by setting the 
VSL packed word, INTENT, to 0), and its effect is examined by the ADVEVL sub- 
routine. 

Figure 21 shows a detailed computer flow chart for the TRYVSL subroutine. 
If the threat is diverging in range, then the negative advisory is chosen by 
setting the first "bit" of INTENT. (Interpretation of INTENT bits will be 
explained later.) If the threat is converging, then the weakest advisory 
(i.e. , limit vertical speed to 2000 fpm) is tested by invoking the VSLINT sub- 
routine. If this is sufficient (the vertical-speed-limit-OK flag, LVSLOK, = 

1), then the corresponding INTENT bits are set. If it is not satisfactory, 
then the next stronger advisory is tested. This process is continued (see 
Figure 8) until the negatives (don't climb/descend) are tested. If it is safe, 
then the first INTENT bit is set. Otherwise, the positive advisory is tested 
by setting INTENT to zero and invoking the ADVEVL subroutine. 

Figure 22 shows a detailed computer flow chart for the VSLINT subroutine. 
Its function is to test the vertical miss distance with the assumed resolution 
vertical speed. This is done by testing the projected altitude separations at 
two critical times — the range tau and the modified range tau. Actual testing 
is performed by the VSLTST subroutines. It is noted that the safety margin is 
modified by the ALIMOD amount. 
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Figure 19. SELADV Detailed Flow Chart 
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Figure 20. CHKPRJ Detailed Flow Chart 
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Figure 21. TRYVSL Detailed Flow Chart 
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Figure 22. VSLINT Detailed Flow Chart 
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Figure 23. VSLTST Detailed Flow Chart 
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Figure 23 shows the detailed flow chart for the VSLTST subroutine which 
does the testing at each of the two critical tau's. First, the projected 
altitude separation is computed based on the altitude rate defined by this VSL 
advisory (z Q ) , the critical tau (t) , delay time (5 or 0 sec) and the sense 
indicator (LSENSE) . Table 24 defines the conditions and definitions of the 
separation, VMDP. Then, the projected vertical separation is compared with 
the modified safety limit. Depending on the in-threshold flag, INTHR, the 
vertical-speed-limit-OK flag (LVSLOK) is set. LVSLOK = 1 signifies that this 
speed limit is satisfactory. 

Figure 24 shows a computational flow chart for the ADVEVL subroutine. 

It is remembered that the ADVEVL routine is called if a VSL or a negative 
advisory was not found, and a positive advisory must be issued. Also, the 
separation due to a positive advisory was never computed or tested. This 
routine does just that. First, the desired Own speed is computed (0,+1500 fpm, 
or Own current speed) . Then based on the desired altitude rates, the expected 
vertical miss distance is computed. See Table 10 for this computation. If 
the expected separation exceeds the 100 ft safety limit, then set the advisory-. 
not-OK flag (LADNOK) to 0. If the separation is within the 100 ft limit, then 
LADNOK is set to 1. 

Table 24. VMDP Computation Table 


LSENSE 

z 0 (fps) 

VMDP (ft) 

-1 

(descend) 

> ZDG 

zj = ZPROJ (z Q , Zq , T', 5.0, ZDG, LSENSE)* 
VMDP = zj -(z T + z T ~T') 

£ ZDG 

A ^ ^ 

VMDP = (z Q — Zrp) + (ZDG - z T ) t' 

+1 

(climb) 

1 

< - ZDG 

Zq = ZPROJ (Zq, Zq, T', 5, - ZDG, LSENSE) 
VMDP = Zq - (z T + z T t ') 

£ - ZDG 

VMDP = (zq - z T ) - (ZDG + z T ) t' 

*Zq is the 

projected altitude at if ZDG is the desired rates. See Eq (30) • 
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Figure 24. ADVEVL Detailed Flow Chart 
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The fact that this flag is set to 1 indicates that the CAS logic cannot find 
a satisfactory resolution (positive or otherwise); therefore, the pilot must 
be warned immediately. This concludes the Resolution Advisory Selection 
module description. 

Advisory Packing and Outputting There are four routines which pack the 
CAS file - PACKRA, SPCLRA, PACTA, and PACKPA. The CASOUT routine goes through 
each entry in the CAS file and "summarizes" the output. These routines are 
dependent on the external device which utilizes the output data. Therefore, 
they should be modified according to the external device requirements. 

Table 25 summarizes the four packing routine operations. These are not 
necessarily the requirements; however, these are thought to enhance the graphic 
display on the cockpit CRT. 

The CASOUT routine scans through the CAS file and obtains a single set 
of advisory outputs including text. First, the RA threats are scanned, and 
the latest RA is picked, and the outputs are packed. Depending on the LTENT 
flag, the output variables - IDCMD, ZDGOUT and RATEXT - are set through a 
table- look-up procedure performed by the RAMAP routine. The relationsnips 

among LTENT, IDCMD, ZDGOAL and RA TEXT are given in Table 26. 


Table 26. CAS Output Variable Map 


— » 

LTENT 

IDCMD 

ZDGOAL 

RA TEXT 

01000 

-1 

0 . 

WARNING 

00000 

1 

1500. 

CLM 

10000 

2 

0 . 

DDES 

11001 

3 

-500. 

DDES 500 

11010 

4 

-1000. 

DDES 1000 

11011 

5 

-2000. 

DDES2000 

00100 

6 

-1500. 

DES 

10100 

7 

0 . 

DCLM 

11101 

8 

500. 

DCLM 500 

11110 

9 

1000. 

DCLM1000 

11111 

10 

2000. 

DCLM2000 
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Table 25. CAS File Variables Stored by the Packing Routines 



CAS File 
Variables 

PACKRA 

SPCLRA 

PACKTA 

PACKPA 

IDSTS 

3 

-3 

2 

1 

LTENT 

INTENT (+100) 

■ l 

0 

0 

TMCAS 

TIME 

1 

TIME 

TIME 

TMCPA 

TAU1 


TAU1 

0 

XCPA 

A • 

Ax + • Ax 

■ 

* * (21 
Ax(+ . Ax) ' ' 

0 




£ 


YCPA 

Ay + . Ay 


Ay(+t 1 . Ay) 

0 

DZCPA 

- c 

Az + . Az 


A • 

AzC+x.^ . Az) 

0 

ZDGOAL 

ZD G 

0 

0 

0 

IRAFLG 

x (3) 


- 

- 

ITAFLG 

1 ; 


- 

- 

IPAFLG 

1 


1 

- 



(1) LTENT — INTENT + 100 implies that the third bit is set if 

LSENSE is negative (descend) . 

(2) If t >_ 0. 

(3) These are set elsewhere in CASSTS. 
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This table corresponds directly to Table 15 with IDCMD matching the RA Map Num- 
ber. (IDCMD = -1 was added to account for the special RA case applicable to the 
pop-up threat.) The difference between INTENT and LTENT is that LTENT con- 
tains the climb/descend (LSENSE) bit. The third bit of LTENT is the sign 
bit, (i.e., if it is 1, then the selected sense is descent. LTENT is part of 
the Packed Word (OWNTENT in the MITRE logic). These are (8, 7, 6, 2, 1) bits 
from the right. 

This concludes the description of the BXTCAS simulation program. The 
sensor simulation part is believed to be operationally accurate. At least 
no significant parts are knowingly omitted. An approximation was made for 
computing the next schedule time. The CAS logic simulation part follows the 
MITRE logic(as represented in the draft TCAS MOPS [2] by the pseudo E-code) . 
There are a few exceptions. These are: 

(1) Only the vertical logic is simulated; 

(2) The coordination logic between TCAS systems is not simulated; 

(3) The multi-threat logic is not included; and 

(4) The altitude tracker algorithm is entirely different. 


Some comments and remarks are in order . 


(i) At this time only the vertical logic is sufficiently mature to 

construct a simulation model. The horizontal logic is considered 
to be at a design stage. Our previous model was updated due to 
specification changes especially in the detection logic. 

(ii) The coordination and multi-threat logic are not included in the 
simulation because of no immediate CDTI needs. These two func- 
tions add a substantial complexity to the program without appar- 
ent or direct CDTI research pay-off. 

(iii) The CAS logic contains dedicated estimation functions which are 
performed in range and altitude axes. In the present simulation 
this function is imbedded into the sensor module. Furthermore, 
the estimation function is carried out in an Own attitude sta- 
bilized north-east-down coordinate system. 

(iv) The vertical tracker algorithm implemented in the simulation 
program is based on the work reported in Ref. 1. Its perfor- 
mance is expected to be similar to the MITRE design; however, 
the coding requirement is less in terms of memory. See Ref. 1 
for the detailed description and performance analysis. 
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IV 


SIMULATION VALIDATION 

The BXTCAS simulation program is written in standard Fortran IV and is 
highly transportable among general purpose main-frame computers (CDC-7600, 

CRAY X-MP) or mini-computers (VAX 11-780). The program contains approxi- 
mately 3,000 lines of source code including a simple traffic generator. 

During the course of the development of the BXTCAS, the TCAS simulation 
program was imbedded into a semi— real time operating environment to help de- 
bug, exercize and validate the TCAS module. These efforts were carried out 
essentially in two steps - the sensor part and the CAS part. 

An earlier version of the TCAS simulation module was implemented in a 
real time active simulator at NASA/Langley Research Center. It was used to 
drive a CDTI display with a realistic traffic pattern and full pilot work-load 
experiments in April, 1984. This proved the utility of the program. 

In this chapter, the TCAS simulation validation efforts are discussed, 
and results are presented. 


Simulation Set-Up 


Figure 25 shows a detailed flow chart of the simulation set-up to exer 
cize and validate the TCAS module. It consists of the following elements: 

ACDY: Air traffic (40 aircraft including Own) generation routine 

integrated at 0.5 sec interval; 

ACIC: Initialization routine for ACDY; initial values are selected 

randomly; 

XNSFR: Creates the TCAS input file from the traffic generation 
routine; 

BXTCAS: Traffic sensor and vertical collision avoidance logic model 
based on the Bendix enhanced TCAS II design; and 

OUTPUT: Output routine. 
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Figure 25. TCAS Simulation Validation Program 
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The aircraft dynamic states are integrated every 0.5 sec to minimize 
the numerical integration error. By closing the time loop around the traf- 
fic generator, semi-real time operation is achieved. The kinematic variables 
are input to the BXTCAS module through a data transfer routine (XNSFR) every 
second (because of the ISMPL flip-flop) . After the call to BXTCAS results are 
printed (or stored in arrays) through the OUTPUT routine, then the time is 
advanced by 0.5 sec and this cycle is repeated. It is noted, however, that up 
to 40 aircraft are generated during the same time frame and the kinematic data 
concerning all aircraft are transferred. simultaneously . In a real system, at 
least the surveillance operation would be performed one aircraft at a time 
distributed over one second. The processing of the surveillance data may be 
timed at one second intervals, if the surveillance data are stored in a buffer. 

As mentioned previously, 40 aircraft are generated in ACDY by using 
simple point-mass 7-state dynamic equations. The details are given in Figure 
26 and Table 27. The feedback loop in each control axis results in a first order 
lag characteristics between the command and response. This gives altitude or 
airspeed hold capability. The lateral axis is assumed to be coordinated. The 
pitch angle is assumed to be the flight path angle. The cross-feed of the 
pitch error to the airspeed loop is introduced to simulate the difference in the 
respective loop closure time constants. 

The various rate and authority limits are thought to represent commercial 
airliner operations. The states are integrated using the second order Euler 
(trapezoidal) method. 

The state and command variables are initialized in the ACIC subroutine. 
Nominally, Own aircraft is placed at the origin flying due north with level 
flight at 6000 ft altitude and 200 kt airspeed. Other aircraft are initial- 
ized with respect to Own. The initial pitch, heading, airspeed, range, bearing 
and relative altitude are drawn from uniform density functions. The north- 
east-down coordinate positions are then computed from the range, bearing and 
relative altitude values. The roll, pitch and airspeed commands are initial- 
ized to the corresponding state variables so that there will not be initial 
transients. Table 28 lists the specific numerical values chosen for the 
validation cases. The randomized initialization (Monte Carlo) method was 
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Figure 26. Simplified Command-Response Based Point Mass Aircraft Dynamic Model 





Table 28. Traffic Initialization 


Own 

Aircraft : 


X 

= y - o 

(origin) 

z 0 

= -6000 ft 


* 

= 0.0 

(due north) 

V 

= 200 kt 


a 



6 

= 0 

(level flight) 


<J> = 

0 



0 

e U [-20, 20 deg] 



* 

e U [-180, 180 deg] 



V 

a 

e U [100, 200 kt ] 



rng 

e U [2, 60 nmi] 



brg 

e U [-180, 180 deg] 



Az 

e U [-3000, 3000 ft] 



X 

= rng • cos (brg) 



y 

= rng • sin(brg) 



z 

= Zq + Az ; U [a,b] 

= Uniformly distribu- 
ted random number 
between a and b 

Commands initialization 


= 0 



0 

c 

= 0 



V 

ac 

= V 

a 




Target Aircraft 


(39 aircraft within 60 nmi) 
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adopted so that all the targets are targets of opportunity. Therefore, 
no specific traffic can be catered for a specific purpose to "control" the 
experimental outcome. This method may not encompass all the important cases; 
however, omission is not by intention, and the somewhat large volume of traf- 
fic (39 aircraft) should provide a certain protection. 

Commands are generated in an open loop manner by a timed table look-up 
procedure. Thus, they are piecewise constant time functions. The command 
tables are chosen arbitrarily within reasonable operational limits. One short- 
coming of this method is that the chosen traffic patterns do not simulate speci- 
fic air traffic control patterns or scenarios. Therefore, it would not be ef- 
ficient if the desired outcome depends on the scenario such as in the CAS 
applications. For testing and validating the traffic sensor module, the above 
method should be adequate. 

Own state variables and target kinematic variables are transferred to 
the BXTCAS subroutine by means of two input commons, /OWNINP/ and /TGTINP / 
by the XNSFR subroutine. These are given by Table 16. 

The validation of the BXTCAS module was performed in two stages - the 
sensor and CAS logic portions. The sensor validation results are discussed 
next followed by the CAS logic section. 

BX TCAS Sensor Validation 

During the course of the simulation development, numerous cases were 
run. Several cases are chosen and the simulation results are discussed. 

For the sensor validation purposes, the initialization of the aircraft state 
variables are as discussed in the previous section. Different cases are 
obtained by choosing different command tables. The four validation cases 
are listed below. 
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Case (1) - 120 sec run 

Own: straight and level flight due north at 200 kt and 6000 ft 

(no maneuvers) . 

Others: constant horizontal and vertical flight path angle flight; 

position and velocity are initialized from uniform density 
functions. 


Case (2) - 120 sec run 

Own: straight and level flight due north at 200 kt and 6000 ft 

altitude. 

Others: Two aircraft (648 and 840) are commanded the following 

roll and pitch maneuvers: 


A/C 648 

- at 

t = 

15, 

60, 

and 

105 

sec, 

* 

=15, -15, and 0 deg; 


at 

t = 

15, 

75, 

and 

90 

sec, 

6 

c 

= 7, 0, and -10 deg. 

A/C 840 

- at 

t * 

15, 

60, 

and 

105 

sec, 

<t> c 

= -15, 15, and 0 deg; 


at 

t = 

15, 

75, 

and 

90 

sec. 

e c 

c 

=7, 0, and -10 deg. 


Case (3) - 180 sec run 

Own: straight and level flight due north at 200 kt and 6000 ft 

altitude; at times 15, 45 and 150 sec, Own makes roll maneu- 
vers of 20, 0, and - 20 deg, respectively. 

Others: constant horizontal and vertical flight path angle flight; 

position and velocity are initialized from uniform density 
functions. 


Case (4) - 120 sec run 

The high frequency measurement errors are introduced. The error 
magnitudes are: 


° r = 75 ft (range); and 
= 1.5 deg (bearing). 

Case (1): Figures 27 (a) through 27 (f) show the simulation results. 

These are explained and discussed. 

Figure 27 (a) shows the horizontal projections of all the tracks within 
25 nmi of Own. True, measured and estimated positions are shown respectively 
from left to right. The target tracks are relative, i.e.. Own aircraft is 
at the origin throughout the simulation period. There are 17 tracks within 
25 nmi of Own. The true positions are shown every second. The measured positions 
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are shown according to the sampling periods computed by the scheduling al- 
gorithm. The estimated positions are shown corresponding to the measurement 
times. The latter two figures show the effects of the variable sampling 
periods and of the different (track or acquision) regions. These will be- 
come clear when the individual time plots are discussed. 

Figure 27 (b) shows time lines of events associated with individual air- 
craft. For example. Aircraft No. 840 begins in the acquisition region; at time 
t = 40.5 sec it transitions into the track region and stays in the region 
for 60 sec; at t = 104.5 sec it exits back to the aquisition region. The time 
line shows the dynamic nature of the internal traffic file updates. Several 
aircraft are deleted from the file as they fly through the acquisition region; 
and a few individual aircraft are added to the traffic file as they fly into 
the acquisition region. 

Figures 27 (c) through (f) show the time, plots of true, measured and 
estimate position and velocity components, as well as estimation errors for 
aircraft in the track region. Figure 27 (c) shows the aircraft No. 144. The 
true, measured and estimated x and y positions are shown in the upper left 
plots. The true and estimated x and y velocities are shown in the lower 
left plots. The position estimation errors are shown in the upper right 
plots, and the velocity errors are shown in the lower right plots. The velo- 
city errors show a small initial transient behavior, but remains small. The 
position estimation error plots show a cyclic behavior; zero, small and 
larger; zero, small, and larger; and so forth. This indicates that the sur- 
veillance schedule for this aircraft is every 3 sec. 

Figure 27 (d) shows similar results for aircraft No. 288. This air- 
craft stayed in the track region approximately 20 sec and was apparently sam- 
pled every 1 sec. At approximately t = 20 sec, there was a surveillance failure. 

The aircraft exited to the acquisition region because of the altitude thres- 
hold rather than the range threshold. 

Figure 27 (f) shows a case where aircraft No. 840 begins in the acqui- 
sition region, flies through the track region, and exists to the acquisition 
region. During the track region, the aircraft was sampled at 2 sec intervals. 
The transient behaviors are similar to other cases. 
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Case (2): Figures 28 (a) through 28(g)/ show the results for Case (2). 

Here, two aircraft (Nos. 840 and 648) underwent roll maneuvers. The 
horizontal projections show these two maneuvering .aircraft very clearly. 

Figure 28 (d) shows the time plots for aircraft No. 840. They show 
interesting points: (1) surveillance failed for four consecutive seconds at 

apporximately t = 20 sec; (2) the velocity errors during the maneuver are 
large (ax of 20 kt and Ay of -18 kt) and the position errors are on the order of 
0.01 nmi, and (3) toward the end of track period (t = 60 sec), the sample period 
becomes 2 sec from 1 sec due to altered geometry. 

Figure 28(e) shows the time plots for aircraft No. 648 with similar 
characteristics. Here, the maximum velocity errors are 45 kt for x and 13 kt 
for y. Because of the changing geometry, the surveillance rate drops to a 2 sec 

interval at approximately t = 25 sec. Because of this lower sampling frequen- 
cy^ the; velocity errors become larger which induce larger position errors. 

Figure 28 (g) shows the time plots for aircraft No. 696. This air- 
craft flies into the track region at approximately t = 95 sec. The samp- 
ling rate is 6 sec. This example shows clearly that the position prediction 

(COAST) routine is working, since the measurement errors increase (be- 
cause the oldest measurement is used to compute error along the current po- 
sition) while the predicted estimates have negligible errors. 

Case (3) : This is the case when Own aircraft makes two roll maneuvers - 

+ 20 deg at t = 15 sec and -20 deg at t = 150 sec. Figure 29 shows the roll, 
yaw-rate and yaw angle time plots. It is seen that the essential dynamic 
characteristics are captured by the simple aircraft model. 

Figure 30 (a) through (f) shows the results for this case. Figure 30(a) 
shows the horizontal projections. The plots show the other aircraft tracks 
in the NED coordinate system moving with Own as it maneuvers. (It is not a 
track-up display.) Therefore, as Own maneuvers it looks as though all other 
traffic is maneuvering. 
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Figure 30(b) Time Line for Case (3) 





















Figures 30(c) through 30(f) show the time, measured and estimated posi- 
tion and velocity time plots. Referring to Figure 30(c) (aircraft No. 

816) , the following comments apply: 

(i) This aircraft started out as a pop-up. After the initial 
5 sec of continuous surveillance, the sampling period 
became a regular 3 sec; 

(ii) The peak velocity errors were -60 and 90 kt for x and y coordinates 
respectively. The transient period was x long - approximately 
30-40 sec; and 

(iii) Because the measurement errors (when they are sampled) are 

zero, the Own attitude effects through the forward and back- 
ward transformations are properly accounted for. 


Figure 30(f) shows the time plots for aircraft No. 696. Two interesting 
observations are: (1) the sampling period changed from 3 to 2 to 3 sec; and 
(2) the position and velocity errors are symmetric with respect to Own’s man- 
euver. The peak velocity errors were -50 and -80 kt for x and y coordinates 
respectively. This case clearly points out an ill effect of the dynamic 
sampling period selection procedure. The sampling period should have been 
reversed, i.e., it should have been two (or even one) sec during maneuvers 
and could have been slower during the straight flight period. 

Case (4) : Figures 31(a) through 31 (i) show the simulation results. 

All the tracks are straight for this case; however, the range and bearing 
measurements contained additive high frequency errors with the standard 
deviation magnitudes of 75. ft and 1.5 deg, respectively. Injection of 
high frequency noise sources does not prove or validate the simulation soft- 
ware per se, once the input-output relationships are proven. However, 
it will provide a certain operational latitude in terms of the system 
robustness; that is, the simulation module does not require perfect . 
information. 

Figure 31(a) shows the true, measured and estimated horizontal tracks 
for this scenario. The measurement and estimation plots show quite per- 
ceivable noise effect. Considering the somewhat small plot scale of 
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Figure 31(a) Horizontal Projection for Case (4) 
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approximately 12 nmi/inch and the "static display" (the entire track 
history dots are seen at once), the measurement noise may have substantially 
worse effects on pilots in the CDTI applications. For example, the 
display scale may be 1 nmi/inch and each history dot may be displayed 
dynamically as they become available. This means that the linear dimension 
would be perceived one order of magnitude larger. 

The time line of events for this case - Figure 31(b) - shows one 
interesting aircraft (No. 504). It begins as an acquisition aircraft until 
T = 74 sec; then it transitions to the track region. It then transitions 
to the acquisition regions at T = 98.5 sec; and then it transitions back to 
the track region at T = 108.5 sec. (Even though not shown, the latter be- 
havior is due to Own’s altitude maneuver.) 

Figures 31(c) through 31 (i) show the time plots for all the aircraft 
in the track region. All of these show the noise effect. The following 
comments summarize the result: 

(i) Position measurement errors are between 0.2 ~ 0.4 nmi; 

(ii) Position estimation errors are generally smaller due to the 
smoothing effect on the a-B tracker; 

(iii) Initial velocity errors are large up to 200 kt; and 

(iv) Sampling time variations of 1 or 2 sec were observed. 

This "performance" is thoughtto be realistic. The actual system is 
expected to behave worse than the simulation, since many factors are not 
incorporated in the simulation program. Two of the important factors are 
(a) the correlation process (of establishing between the targets and measure- 
ments) is 100% reliable with the simulation programs; and (b) the measurement 
errors are assumed to be white noise sequences, whereas for the actual system, 
the errors would be more correlated due to multi-path and reflection effects. 

During the course of debugging and development effort, each module’s 
inputs and outputs are checked and rechecked to validate the software 
comparing with "design" requirements. To that extent the simulation soft- 
ware is validated. 
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Figure 3l(i) Relative Position, Velocity and Errors for A/C 552 - Case (4) 





CAS Logic Validation 


Only certain aspects of the collision avoidance logic were tested, 
since it is highly dependent on the chosen encounter scenerios. Valida- 
tion efforts are pursued by running selected scenerios > and the simula- 
tion results are manually checked to explain discrepancies, if any. 


Two methods were used to set up encounter scenerios. Both required 
modifications in the aircraft initialization routine, ACIC. One was to 
simply fix the initial conditions for the desired geometries. The other 
was to choose desired miss-distances (in three dimension) at future times 
and, by using the randomly selected velocities, the initial positions of the 
targets were calculated back to time 0. Therefore, the target velocities 
were constant but randomized. There are two significant points: 


(i) The vertical tracker with the Mode C altitude reports with 100 ft 
quantization did not have much effect on the CAS logic output, once 
the tracker algorithm was established. 

(ii) The randomized (Monte Carlo) selection of target velocities 
minimizes any subjective intent in the selected encounter scen- 
arios. This feature reduces the number of experiements needed 
to validate the CAS logic module. 


Own aircraft was allowed to maneuver in pitch in an open-loop man- 
ner (not in response to CAS RA advisories). Thus, Own's dynamic effect 

was a factor in the outcome. Figure 32 explains the terminology used in 
defining the encounter scenerio in the horizontal dimension. The important 
variables are the range, range rate. Own and target altitudes and altitude 
rates for defining the encounter in the range and altitude dimension. 

Validation of the Proximity and Traffic Advisories were established by 
manually checking the computational steps in the DETECT subroutine and 
comparing the computer results. This aspect was tested to a certain 
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extent by the NASA/Langley piloted simulation since PA and TA advisories were 
used to color code the concerned traffic within the CDTI symbology. It is 
noted, however, that the current and active simulator versions are different. 

The most notable difference is in the counting procedures in the threat 
detection logic. The older version relied on the so-called two-out-of-three 
rule; whereas the current version does not have this cushion. 

The RA modules (detection, sense and escape maneuver selections) are 
validated in similar ways by mostly manual check of the computation steps. 

Table 29 contains a partial list of CAS encounters tested during this effort. 

The table lists the initial conditions in terms of Own altitude and altitude 
rate, target transponder equippage (2 ATCRBS and 3 Mode S) , relative 
range and range rate, and altitude and altitude rate. These initial conditions 
are defined 20 sec before the advisory issuance time. The CAS logic output is 
shown in the right most column. For example, Scenario No. 1 shows that Own 
and target are both flying level at 11,000 and 11,600 feet respectively. The 
target is equipped with a Mode C transponder, and the relative range was 6 nmi at 
the closing rate of 360 kt (a negative sign indicates that this is a converging 
target). Twenty seconds into the encounter, an RA is issued. At that time, the 
range and modified range closure times (taus) are 39.5 and 37 sec, respectively. 
The specific resolution advisory is a negative (LTENT = 10100 -*■ don't climb). 

See Table 26 for the LTENT definitions. 


Scenarios (i) through (7) are adopted from the suggested test 
scenerios contained in the TCASI II MOPS [2]. These are rather simple 
encounters with Own flying level. Scenarios (8) through (19) are gener- 
ated using the Monte Carlo initialization method. Brief discussions are 
given below. 


Scenario (1): The minimum x (range closure time) is 27 sec which 

is smaller than the threshold value of 30 sec at this Own altitude; 
the RA threat is declared. The current and future vertical separ- 
tion is 600 ft, which is less than the detection threshold of 750 
ft, and larger than the RA threshold of 440 ft. Since the threat 
is above, the negative "don't climb" advisory is issued. 
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Table 29 CAS Logic Validation Cases 


No. 

z 0 

(ft) 

z 0 

(fps) 

E 

Q 

P 

r 

(nmi) 

• 

r 

(kt) 

So 

• 

(fps) 

Results and Comments 

■ 

11,000 

0 

2 

6.0 


11,600 

0 

x. = 29.5, t 2 = 27.0 LTENT = 10100 (DCLM) 

2 

11,000 

0 

2 

6.0 


10,760 

0 

i 1 = 29.5, t 2 = 27.0 LTENT = 00000 (CLM) 

3 

11,000 

0 

2 

6.0 

-360 

11,200 

0 

x 1 m 29.5, t 2 = 26.3 LTENT = 00100 (DES) 

■ 

11,000 

0 

2 

8.0 

-500 

12,516 

-33.3 

t x = 33.7, t 2 = 29.3 LTENT = 10000 (DDES) 

5 

11,000 

0 

2 

8.0 

-500 

9,517 

-33.3 

x 1 = 33.7, x 2 = 28.3 LTENT = 00100 (DES) 

6 

12,500 

0 

2 

6.0 

-360 

11,800 

■ 

0 

= 29.5, t 2 = 22.1. LTENT = 00000 (CLM) 

■ 

12,500 

0 

2 

6.0 

-360 

12,100 

0 

T- = 29.5, T 2 = 22.2 LTENT = 00100 (DES) 

8 

21,508 

0 

3 

1.15 

-100 

22,513 

-13.5 

r 1 = 19.7, x 2 = 11.0 LTENT = 00100 (DES) 

*Own filter was lagging with z = -25 ft, z = 17.7 

9 

6,033 

41.5 

2 

2 

-166 

7,190 

17.2 

x 1 = 22.1, x 2 - 16.8 LTENT = 11110 (DCLM 1000) 

10 

24,448 

41.5 

3 

B 

-101 

27,212 

~ 13 .5 

x 1 = 32.5, t 2 = 16.9 LTENT = 11110 (DCLM 1000) 

11 

20,903 

34.0 

2 

3.11 

-157.2 

21,877 

22.2 

= 27.3, x 2 = 24.4 LTENT = 11110 (DCLM 1000) 
*Own filter was lagging with z = 30 ft, z= 13.4 
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Table 29. CAS Logic Validation Cases Continued 


No. 

z 0 

(ft) 

*0. 

(fps) 

E 

Q 

P 

r 

(nmi) 

r 

(kt) 


A 

(fps) 

Results and Comments 

12 

8,079 

19.4 

3 

1.27 

-105 

8,810 

-13.5 

t x = 22.8, t 2 = 14.2 LTENT = 00000 (CLM) 

13 

14,079 

19.4 

3 

1.27 

-105 

14,820 

-13.5 

= 22.8, t 2 = 14.2 LTENT = 00000 (CLM) 

14 

14,337 

-35.5 

2 

2.16 

-152 

11,437 

22.2 

= 28.6, t 2 = 22.9 LTENT = 11001 (DDES 500) 

15 

26,237 

-35.5 

2 

2.16 

-152 

23,437 

22.2 

t 1 - 28.6 t 2 - 22.9 LTENT = 10000 (DDES) 

16 

14,872 

-35.5 

3 

0.03 

65.2 

14,500 

-13.5 

T 1 = 0, t 2 = 10 LTENT = 10100 (DCLM) 

*Range Divergent 

17 

26,872 

-35.5 

3 

0.03 

68.3 

26,500 

-13 .'5 

T l=0 t 2 =10 LTENT = 10100 (DCLM) 

*Range Divergent 

18 

11,626 

-41.5 

2 

1.28 

-52.1 

8,198 

24.5 

t 1 = 32.3, t 2 = 26.6 LTENT = 10 000 (DDES) 

19 

23,584 

-41.5 

2 

1.26 

-52.1 

20,222 

24.5 

t 1 = 31.4, t 2 - 25.7 LTENT = 00000 (CLM) 


i 












































































Scenario (2) : This situation is similar to (1) except that now the 
vertical separation is 340 ft. This is less than the RA threshold. 
Because the target is below Own, a positive climb is issued. 


Scenario (3) : This is similar to (2) except that the threat is 200 ft 

above, resulting in a positive "descend" advisory. 


Scenario (4): In this scenario, the target is descending at 33.3 

fps (2000 rpm) . It would be within 540 ft of Own altitude at the 
critical time. Since the separation is not within the RA threshold 
a negative "don't descend" is issued. 


Scenario (5): This is a symmetric case of (4). However, the worst 

case separation (vertical miss-distance) is within the RA threshold, 
and the target will be above during the critical interval; thus, a 
positive "Descend" is issued. 


Scenarios (6) and (7): These cases do not need explanation. See (2) 

and (3). 


Scenario (8) : This was a case when Own was in the middle of a 

"pitch-down-to-level " maneuver. Consequently the Own altitude 
and altitude-rate are in error by -25 ft and 17.7 ft/sec, res- 
pectively. Figure 33 depicts the situation. Because Own has 
leveled-off and the miss-distance would be 460 ft, the correct 
RA would have been "Don't climb". Because the Own estimator was 
lagging the miss-distance computed from the estimates was in error 
by 357 ft resulting in the positive "Descend" advisory. Fortunately, 
the wrong advisory did not induce a worse situation. 


Scenario (9): This case shows an example of a vertical speed limit. 

The miss-distance is approximately 100 ft over the critical interval. 
The target is above throughout the encounter. Thus, the descend 
sense is selected. The vertical rate of +2000 fpm is tested, and it 
fails. But the vertical rate of 1000 fpm satisfies the RA threshold. 
Therefore, this is selected as the speed limit, resulting in the "Don't 
climb faster than 1000 fpm". 
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Altitude 



Figure 33. Schematic Diagram for Scenario (8) 
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Scenario (10) : The vertical miss-distance is approximately 130 

feet. During the critical time period. Own and target altitudes 
cross each other. The negative sense is chosen for obvious 
reasons. However, if the vertical speed was no faster than 1000 
fpm, the initial separation will remain safe throughout the critical 
time period; thus, a VSL M Don f t climb faster than 1000 fpm” is 
selected. 


Scenario (11) : This is a wrong advisory case due to Own estimation 

errors. Actual RA should be a negative "Don’t descend” instead of 
"Don’t climb faster than 1000 fpm”. 


Scenarios (12) and (13): These two are identical except for altitude. 

Because the miss-distances were smaller than the threshold value be- 
low 10,000 ft; therefore, the RA is identical for both cases. 

Scenarios (14) and (15) : These two are identical except for the 
altitude. The RA vertical threshold is 440 ft for (14), and 640 ft 
for (15) . The vertical miss-distance is approximately 100 ft below 
Own. A positive (climb) sense was chosen. The vertical speed limits 
were tested sequentially. The smaller limit was satisfied first for 
(14) . It took an extra ’’altitude rate margin” to satisfy the larger 
limit for (15). See Figure 34. However, DDES is one ’’rank” stronger 
than DDES 500. 


Scenarios (16) and (17): Again, these are identical except for the 

altitude. These two cases are continuations of cases (12) and (10), 
respectively. Because of the antenna shadowing due to the pitch 
maneuver, this particular target came out on the "other side". Be- 
cause of the target proximity, it passed the non-convergent range 
test. This is shown as x^ being 0 and X£ being limited to 10 sec. 

Because the current altitude separation is small for both cases, the 
selection logic selects a negative "Do not climb". 


Scenarios (18) and (19) : These are two identical encounters except 

for altitude. Because of the difference in threshold values at 
different altitudes, the chosen advisories are different. One is 
negative (Don’t descend), and the other is positive (climb). 
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Figure 34. Comparison of VSL's at Different Altitudes 
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Many more encounter scenarios were examined than discussed in the text. 
We have reasonable cause to believe that the CAS logic is validated with 
respect to the operational and functional characteristics as discussed in the 
text. An examination of the test scenario indicates that the major portion 
of the CAS logic is captured faithfully in this simulation. The logic was 
tested with somewhat benign traffic patterns -no horizontal or vertical 
maneuvers by the target. Furthermore, no measurement errors were introduced 
to test the CAS logic robustness. 

In conclusion, the simulation is validated from the input/output re- 
lationship view-point in the following sense: 

(a) it obtains operationally correct surveillance/measurement data 
given a traffic pattern; 

(b) it provides correct position and velocity estimates given the 
surveillance data; 

(c) it makes correct threat assessment given the estimates; and 

(d) it generates correct CAS advisory given the estimates and the 
threat assessment. 

However, this does not imply that the resultant advisory is "correct" 
in avoiding a near-miss because the "correct" position and velocity estimates 
do not imply "error-free". It is felt that the altitude measurement and 
estimation errors would be the most critical elements. 
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V 


CONCLUSIONS 


A comprehensive simulation program was developed of the Enhanced 
TCAS II system based on the Bendix design. The program is written in 
standard Fortran IV, and it is highly transportable among main frame or 
mini-computers (CDC-7600, CRAY X-MP, VAX 11/780). The size of the pro- 
gram is approximately 3,000 lines of source code including a simple 
traffic generation module. It is designed so that it can operate in 
semi-real time. There is no reason why the program cannot be installed 
into a real-time simulation environment (without any modification) , if 
the host executive has a one second background priority loop. 

Both the traffic sensors and the collision avoidance logic modules are 
validated with respect to the known operational characteristics. Some 
limitations are imposed, mostly because of convenience and computational 
complexity. These are defined in the text. 

The program is believed to be a valuable tool, not only for simulation 
but also for analysis purposes. 
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APPENDIX A 


Major Program Commons 


This appendix provides the list of major 
commons used by the program. The commons 
are listed in Table 18. 
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TABLE A. 1/OWNTFL/and/lTLGT/ COMMON DEFINITIONS 


PROGRAM 

NAME 

ENGINEERING 

SYMBOL 

UNIT 

COMMENTS 

TIME 

t 

sec 

System time 

xo 

X 0 

nmi I 

Own north-east coordinate 

YO 


nml j 


ZO 

z o 

ft 

Altitude above MSL 

VO 

v 0 

kt 

Ground speed 

ATT(l) 

♦ 

rad 


(2) 

0 

rad 

Attitude angles 

(3) 

TBL(1,1) 

(1,2) 

* 

W 1 - 1 ) 

rad 

> 


• 

• 


T__ (body to local-level) trans- 
^ formation 

• 

• 


(3,*2) 

(3,3) 

t bl (3 > 3) 



SFO 

- 

- 

NOT ACTIVE 

IALO 

IhQ 

100 ft 

Mode C altitude 

RALT 

h°R 

AGL 

ft 

Radio altitude 

ZGRND 

!agl 

ft 

Altitude above ground level 

ZOM(l) 

!o 

• 

ft 

Altitude and altitude rate estimates 

(2) 

z 0 

fps 

Altitude and altitude rate estimates 

(3) 

Z 0m 

ft 

Own altitude measurements 

NTZO 

- 

- 

Altitude estimate initialization flag 

ITRGT 

- 

- 

IDF of pilot selected CDTI target 

IWOW 

— 


Weight-on-wheel switch (1 -»■ on 
ground 

MANSEN 



TOAS operating mode (0, 1 + 2 -*■ 
stand-by; 3-7 -* manual sensitivity; 
8 -*■ automatic) 
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TABLE A. 2 / BNDXFL / COMMON DEFINITIONS 


— — • • •■ 1 1 1 i 

PROGRAM 

ENGINEERING 



NAME 

SYMBOL 

UNIT 

COMMENTS 1 

IDF* 



Target Identification Number 

IDM 



'Previous IDF (sign is used as tracker stations; 

MXN 



Transponder type (1 ■►Mode A, 2’*’ Mode C, 
3 Mode S) 

NXTS 



= -| IDF| -* no need for surveillance 

IRPT 



= 0 invalid report 

NPOP 



= 1 -»• pop-up target 

NSTS 



Advisory status counter 

TNXT 

^XT 

sec 

Next scheduled surveillance time 

TLST 


sec 

Last valid surveillance time 


LST 



RNGT 

BRGT 

r 

b 

nmi 

rad 

True range, bearing altitude 

ALTT 

Z T 

ft 


SFT 

- 

- 

NOT ACTIVE 

RNGE 

r 

nmi | 

Range and bearing errors 

BRGE 

b 

rad f 


RNGM 

r m 

b 

m 

nmi ) 


BRGM 

rad ' 

Range and bearing measurements 

EPSM 

e 

m 

rad 

Look-up angle 

IALT 

Ih,p 

100 ft 

Mode C altitude report 

DXM 

lx 

nmi ) 


DYM 

m 

nmi ^ 

" Measured north-east components 

Ay 
. m 

DXH 

A 

Ax 

nmi s 


DYH 

- A 

Ay 

nmi | 

Horizontal position and velocity estimates 

DXDH 

* 

Ax 

nmi/ sec 1 

i 

DYDH 

$ 

Ay 

nmi/sec > 


DXP 

Ax + 

nmi ] 

1 

DYP 

Ay + 

nmi ^ 

1 Coasted horizontal position 


*These are all arrays of twenty. 
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TABLE A. 3 / ZTRKCFL/ and /ZWRKVR/ Common Definitions 



PROGRAM 

NAME 

ENGINEERING 
SYMBOL UNIT 

COMMENTS 

ICZ* 

- - 

Initialization flag; also used as 


HALT(l) 

(5) 

THAL(l) 


Ih(t ± ) 


100 ft 


vertical profile status index 


Latest (1 = current) five valid Mode 
C reports corresponding to TMALS. 


• 

(5) 

C i 

sec 

LSV(l) 

(2) 

(3) 

L<t LS> 

100 

TSV(l) 

(2) 

(3) 

fc LS 

sec 

TZIC 

T o 

sec 

ZSV(l) 

(2) 

(3) 

Z m^ fc LS^ 

ft 

ZH 

/V 

Z I 

ft 

ZDH 

$ 

z z 

fps 

ZEXT 

Z T 

• 

ft 

ZDEXT 

Z T 



Times of latest five valid Mode C 
reports 


£ t v Latest three Mode C level values 
I corresponding to times TSV 

' Latest three level switching times 

Initialization time 

) Altitude inferred at the time of 
| devel switching times 


Internal attitude and altitude rate 
estimates 


External altitude and altitude rate 
estimates 


*These are all arrays of twenty elements 


LOSWCH - Level 


ITST 
TDUMMY 
Z DUMMY 


Level switching flag (1 -*■ level 
switched 


Used as temporary memory ; arrays 
of five elements. 
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TABLE A. 4 /WORKVR/ Common Definitions 


PROGRAM ENGINEERING 


NAME 


IDENT 

INDEX 

ISURV 

IACQ 

MDX 

DXTMP 

DYTMP 

DZTMP 

ALTMP 

DUMM(l) 

( 2 ) 

(3) 

(4) 

(5) 

( 6 ) 

(7) 

( 8 ) 

(9) 

( 10 ) 


SYMBOL 


RANGE 

Ar 

nmi 

BEARG 

Ab 

rad 

EPSI 

Ae 

rad 

EPS1MX 

Ae M 

rad 

RNGACQ(l) 

Ar ACQ 

nmi 

(2) 

nmi 

(3) 


nmi 

STMAX 

v 

•MAX 

kt 

RLIM 

Sr rl« 

nmi 

RMIN 

ir s 

nmi 

TAU 

T 

hr 

RNGTRK 

Ar trk 

nmi 

DHMTRIG 

A ^trk 

nmi 


COMMENTS 


Temporary identification number 
Temporary file index 
Surveillance flag 
Acquisition/track flag 
Transponder type 

Temporary position variables 


Temporary working memory 


| Range, bearing and look-up angle 

Maximum look-up and down angle = + 23° 
Maximum search range for Mode A = 17nmi 
Maximum search range for Mode C = 17nmi 
Maximum search range for Mode S = 25nmi 
Max. target speed (250-600 kt) ! 

Min. track range (5 or 10 nmi) 

Track range modification = 1.65 nmi 
Track range time period 1/80 hr (= 45 sec) 

} Track region range and altitude boundary 
Computed dynamically 
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TABLE A. 4 /WORKVR/ Common Definitions Continued 


PROGRAM 

NAME 

ENGINEERING 

SYMBOL 

UNIT 


COMMENTS 

TMPWRK(l) 

(2) 

r 

nmi 

* RNGSQR* 
~ TSTRNG = 

range computed from x and y 


nmi/ sec 


nmi/sec 


ALFAH(8) 

a 


BETAH(8) 

6 


Q 

q 


SFMX 

_ 

•4 

SIGZ 

- 

— 

SIGR 

a r 

nmi 

SIGB 

a b 

rad 

DELTH 

AP v 

ft 

DELTP 

ap h 

nmi 

IRPTMX 

- 

- 

PRBTHR(l) 



(2) 

Prob 



estimates 
^ TSTALT 

* VDOTP 

^ RNGDOT = true range rate 

* TSTRRD 

% TAU1 = range closure time limited 
by TVPCMD 

* SPDSQR 

^ TAU2 = modified range closure time 
limited by TVPCMD 

'v- TSTDST 

^ RDTMP = range rates limited by 
RDTHR for 0 divide-check 

* DELZD 
^ DZMOD 

| Horizontal tracker gains. See Table 3 

Mode C altitude quantization = 100 ft. 

| THESE SHOULD BE 0. 

Range error standard deviation 
= 0.0123 nmi 

Bearing error standard deviation 
« 0.01745 rad 

Surveillance altitude threshold 
= 250 ft 

Surveillance horizontal position 
threshold = 0.1645 nmi 

Number of maximum allowable surveil- 
lance failures -1=4 

Surveillance reliability for Mode A = 
0.9 

Surveillance reliability for Mode C = 
0.95 

Surveillance reliability for Mode S = 
0.99 


*Equivalenced in DETECT subroutine. These are mostly temporary in nature 
except ones with comments. 



TABLE A. 5 /CASFIL/Common Definitions 


PROGRAM 

NAME 

ENGINEERING 

SYMBOL 

UNIT 

COMMENTS 

NTADV* 

NCAND + 

IDCAS 

IRACNT 

ITACNT 

ITAFLOT 

IPACNT 

IPAFLG 


) 

J 

Number of threat advisories this cycle 
Identification of threat candidates 
Contains threat IDF of /BNDXFL/ 

RA, TA and PA counters and status flags 

TMCNT 

IDSTS 

IDCMD* 


sec 

Absolute 10 sec timer 

Advisory status flag (1 PA; 2 TA: 

3 -> RA and negative * pilot discre- 
tion) 

NOT ACTIVE 

TMCAS 

t CAS 

Z DG 

sec 

Time of CAS advisory generation 

ZDGOAL 

fps 

Individual vertical speed reference 

TMCPA 

t CPA 

sec 

Time to CPA 

XCPA 

Ax cpa 

nmi 

> x, y, z position at CPA 

YCPA 

Ay CPA 

nmi 

DZCPA 

Az cpa 

ft 

* 

ZDGOUT* 

NTRA* 

LTENT 

RATEXT* 

• 

Z 0UT 

fps 

Over-all vertical speed reference 
Number of RA threats 
Packed word 
RA test output 


*Single variable 
+ Array of 10 elements 

All others are five element arrays. 
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TABLE A. 6 /CWRKVR/ and /CWRKV2 /Common Definitions 



PROGRAM 

NAME 

ENGINEERING 

SYMBOL 

UNIT 

COMMENTS 

NDXCAS 



Number of candidate threats 

JDX 



Temporary CAS file index 

NORA 



No RA capability flag 

LVLOWN 



Own sensitivity level 

LVLINT 



Target (and total) sensitivity level 

LPA 


] 


LTA 

LRA 


1 

j PA, TA, RA Detection flags 

TSTTAU 

T 

r 

sec 

Range closure time 

TAUVRT 

T 

V 

sec 

Altitude closure time 

ZDG 

• 

Z G 

fps 

RA vertical speed reference 

DELZ 

Az 

ft 

Current altitude separation 

VMD 

Az + 

ft 

(Projected) vertical miss-distance 

INTENT 



RA packed word 

IHTHR 



Within threshold (ALMT) flag 

LSENSE 



Climb/descend sense 

LDCFLG 



Don’t care flag 

LVSLOK 



Vertical speed limit RA OK flag 

LADNOK 



Advisory Not OK flag 

ZMPCLM 


ft 

Projected vertical separation for climb 

ZMPDES 


ft 

Projected vertical separation for des- 
cend 

ZPSECH 


ft 

Projected vertical separation for 
second choise 
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TABLE A. 7 /CASPAR/ Common Definitions 


PROGRAM 

ENGINEERING 



NAME 

SYMBOL 

UNIT 

COMMENTS 

DMODT 

Al TA 

nmi 

Minimum range guard for TA modified 
tau 

DMODR 

At RA 

nmi 

Minimum range guard for RA modified 
tau 

TAUTA 

e RTA 

sec 

TA tau threshold 

TAURA 

®RRA 

sec 

RA tau threshold 

TVPCMD 

T 

sec 

Vertical tau limit value 


VC 

o 


HI 

9 (6HRA) 

nmi /sec 

r . r threshold for diverging range 

RDTHR* 

• TA 
min 

nmi/ sec 

Minimum range rate for 0 divide 
check = 10 kt 

ZTHR* 

9 

Z 

ft 

Detection altitude separation 
threshold 

DZTHR* 

S6 Z 

ft 

Vertical threshold modification 
= 60 ft 

ALMT* 

0 

ft 

Resolution altitude separation 

a 

threshold 

ZDTHR* 


fps 

Minimum vertical speed for 0 divide 
check = -1 fps 

ZDLVL* 



NOT ACTIVE 

DZDSML* 



NOT ACTIVE 

ZDCMD(7) 



NOT ACTIVE 

KSEQ(6,7) 



NOT ACTIVE 

RCOAL 

°RCA 

nmi 

Minimum range at co-altitude 

RTHRTA 

ic 

0 ArTA 

nmi 

Minimum range threshold 

TA1LDS 


nmi 

Minimum range guard for modified 
tau = 0.247 

RTSTMX* 


nmi 

Maximum effective RA range = 12 nmi 


*SingIe variable 

All others are five element arrays unless specified. 
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APPENDIX B 


DY TCAS II MODEL CONSIDERATIONS 


Introduction 

In this appendix, DV TCAS II is discussed from the simulation view- 
point. The operational characteristics are summarized in Table 1. The 
DV TCAS II possesses a bearing accuracy of 6-8 deg rms which should be 
sufficient for most, if not all, of the perceived CDTI applications. 

There are three major differences between the DV TCAS and BX TCAS, 
mainly in surveillance functions. These are: 

(1) wide angel (90 deg) directive transmit antenna and quadrant 
monopulse receiver processing; 

(2) regular interrogation interval (1 sec); and 

(3) aircraft body fixed coordinate system. 

The system is essentially a range-altitude system with the angle- 

of-arrival (bearing) information used to satisfy the cockpit horizontal 

display needs. In order to operate in a high traffic density (0.3 air— 

2 

craft/nmi ) area, extensive use is made of multiple level whisper /shout 
interrogations. This is the technique used to minimize "fruit" and 
"garbles". 

The impacts of items (1) and (2) are several: 

(a) smaller effective beam reach; 

(b) different internal acquisition/ track processing; 

(c) somewhat less surveillance reliability which may be range 
dependent; and 

(d) larger bearing error. 
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The impact of the body fixed corrdinate system results in a distortion 
of horizontal projection of the surrounding traffic because the Own body 
attitude is unaccounted for. 

Implementation of the above aspects into the BX TCAS simulation program 
are considered further in the following sections. 


Surveillance Function 

Coverage volume, reliability and sampler logic . As stated above DV 
TCAS does not schedule interrogation. It transmits interrogation pulses 
over a 90 deg angular sector every 1 sec and waits for return signals. 
Therefore, the effective coverage is limited by the transmit and the re- 
ception power levels. These, in turn, "define" the surveillance reliability 
as a function of range. This means that the effective coverage volume is 
provided by a suitable surveillance reliability model. Table B.l lists the 
probabilities of data drop-out (failed surveillance) . It is noted that the 
probabilities depends on the range as well as the past drop-out character- 
istics. The coverage is given implicitly because the probability distri- 
bution depends on the actual range. That is, the probability of obtaining 
surveillance data beyond a certain range becomes extremely low; this, 
effectively limits the beam reach. 

The model is accurate only for the aircraft whose track has been 
established. The "aquisition" phase is approximated by giving a small 
probability of valid signal reception at an extreme range (say 25 nmi) . 

Figure B.l Shows a program flow chart which models the sampler logic. 
This subroutine must be invoked every second with the actual range and 
previous drop-out status. If the surveillance logic is successful, the 
routine returns with the flag IRPT set to 0; otherwise, the flag is 
incremented by 1. If the counter becomes 6, then the target is dropped 
from the internal track file. 
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Table B.l Probability of DV TCAS Surveillance Data Drop-out 


Condition 

1 

Probability of Data Drop-out 

0 <_ range <1 nmi 

0.1 

1 1 <2 

0.13 

2 < <3 

0.15 

3 1 <4 

0.15 

4 1 <5 

0.18 

5 1 <6 

0.21 

(6 grange < 14). AND. 
IRPT ^ = 0 

0.27 

- 1 

0.39 

= 2 

0.59 

= 3 

0.70 

= 4 

0.79 

= 5 

0.85 

(14 i range < 20). OR. 

(b) 

IRPT = 6 

0.95 


(a) IRPT = Number of consecutive drop-out 

(b) Flight test results indicate 1.0 
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START 



Note: Input ■ RNGE(nmi) , IRPT 

Output ■ IRPT 

Data : PROB/O.I, 0.13, 0.15, 0.15, 0.18, 0.21/ 

PR0B6/0. 27 , 0.39, 0.59, 0.7, 0.79, 0.85/ 


Figure B.l Flow Chart for the DV TCAS Sampler Logic. 
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It is noted that the drop-out model was obtained for the so-called 
omni-directional active BCAS (which is a direct predecessor of DV TCAS II) 
based on flight test results. The reliability performance may have improved 
substantially since BCAS because of two design improvements: 90 deg 

antenna directivity and multi-level whisper/shout power sequencing. 

Estimation 

There are two requirements for the estimation functions within DV TCAS. 
One is the need for internal traffic file management including the target 
and measurement correlation by means of a gating technique. The other is 
the CAS logic requirement. As mentioned above, these are performed along 
the range and altitude axes. Therefore, the entire estimation functions 
are developed along these axes. 

An alternative is to use the current algorithm and approximate the 
inverse transformation, as given in Eq (19). That is, the measured Ax and 
Ay are given by 

Ax = Ar cos (ip + Ab) , 

Ay = Ar sin (if> + Ab) . (B*l) 

here, 

Ar = range , 

Ab = bearing , 

and 

^ = Own heading. 

The resulting Ax and Ay measurements are then input to the filter algorithm 
module . 

It is noted that the approximation given by Eq. (B.l) is fairly 
accurate if the roll and pitch angles are small. Also, it can be used to 
support a horizontal CRT display unit in the cockpit. 
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With the above two adjustments, the remainder of the simulation program 
should stay intact. By increasing the bearing noise level to 6-8 deg, the 
resultant program can be used to support the CDTI research effort reflecting 
a less capable system than BX TCAS. 
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